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Tne  purpose  of;  tnis  study  was  to  determine  applications 
for  aatoinaced  management  systems  in  Civil  Engineering  RED 
HORSE  squadrons,  and  to  ina*e  recommendations  for  tne 
development  and  implementation  of  tnese  systems.  Extensive 
interviews  witn  RED  HORSE  squadron  personnel,  and  various 
systems  analysis  methodologies  presented  in  che  current 
literature,  provided  tne  oasis  for  this  researcn  effort. 

The  lengtn  of  tnis  report  suggests  that  I  provide 


t- 


advice  for  tnose  attempting  to  read  and  understand  tnis 
report.  Readers  not  familiar  with  RED  HORSE  squadrons  and 
their  recent  automation  efforts  should  find  tne  oackground 
information  in  Chapter  1,  the  findings  of  Chapter  4,  and  the 
descriptive  models  of  Chapter  5  nelpful  in  understanding  tne 
RED  HORSE  squadron  environment  and  problems  managers  face 
with  tneir  current  manual  information  systems.  System 
designers  should  carefully  review  Appendix  D  and  Chapter  7 
for  more  detailed  descriptions  of  MIS  and  OSS  applications 
and  the  system  capabilities  required  to  support  them. 

Tnis  researcn  and  tne  preparation  of  tnis  tnesis  could 
not  have  been  accomplished  without  the  help  of  others.  I  an 
deeply  indebted  to  the  many  individuals  in  tne  82ucn  and 
823rd  RED  HORSE  squadrons  who  patiently  endured  my 
interviews,  and  provided  tne  data  for  this  research.  I  also 
thank  my  faculty  advisor.  Major  Hal  Rumsey  and  my  thesis 
reader,  Capt  John  Morrill  for  their  continuing  patience  and 
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A o S  C  f  Id  t 

Tne  development  of  automatic  management  s/sti.ns  for 
USAF  Civil  Engineering  Rapid  Engineer  Ueployaole,  Heavy 
Operational  Repair  Squadron,  Engineer  (REP  HORSE;  sguauruns 
das  lagged  bedind  other  Air  Force  Engineering  and  Services 
organizations.  Tne  low  Level  on  automation  in  tnese 
squadrons  may  oe  due  in  part  to  the  differences  in  tne  way 
they  operate  and  a  lack  of  understanding  of  tneir  automated 
management  system  needs.  Tnis  study  defines  tne  automation 
needs  of  RED  HORSE  squadrons,  and  identifies  various 
Management  Information  System  (MIS)  and  Decision  Support: 
System  (DSS)  applications,  by  analyzing  tne  dec  ision-.na*  1  n  g 
information  needs  of  managers  in  these  squadrons. 

Tne  results  of  interviews  with  managers  in  two  RED 
HORSE  squadrons,  as  well  as  a  review  of  regulations  and 
policy  material,  provided  the  data  for  tnis  scuay .  Data 
and  Decision  Analysis  techniques  were  used  to  determine  the 
decision-making  information  needs  of  various  managers  in 
the  squadron.  Descriptive  and  normative  models  of  key 
decision  processes  were  used  to  identify  potential  MIS/DS3 
application  areas.  Key  decisions  were  analyzed  to  identify 
tne  automated  system  capabilities  required  to  support  tnese 
decisions.  Finally,  a  risk  assessment  of  tne  system 
implementation  environment  was  used  to  identify  potential 


The  re sear cn  findings  indicate  the  pri.nary  MI3 
applications  are  reports  of  personnel,  equipment,  ana 
venicle  availaoility ;  training  scnedules;  project  status; 
and  readiness  status  to  tne  different  managers  involved  in 
tne  two  major  squadron  acti v ities--accompl isning  troop 
training  projects,  and  maintaining  comoat  readiness. 
Several  D33  applications  are  recommended  to  provide 
managers  with  support  in  scneduling  training  projects, 
scheduling  individuals  for  training  and  project 


POTENTIAL  INFORMATION  AND  DECISION  SUPPORT  SYSTEM 
APPLICATIONS  FOR  A  CIVIL  ENGINEERING 
RED  HORSE  SQUADRON 

I .  Introduction 

Witnin  Air  Force  Civil  Engineering,  the  Civil 
Engineering  Rapid  Engineer  Deployable,  Heavy  Operations 
Squadron,  Engineers  (RED  HORSE)  are  400-man  squaorons  wnicn 
provide  a  combat  engineering  construction  capability  to 
support  the  USAF  mission  worldwide.  In  peacetime,  these 
squadrons  accomplish  heavy  construction  and  repair  projects 
at  different  bases  to  maintain  proficiency  in  their  wartime 
skills.  The  vast  resources  of  these  squadrons  and  their 
tremendous  construction  capability  require  that  the  managers 
in  these  organizations  make  the  best  possible  decisions  in 
allocating  squadron  resources.  Effective  Decision  Support 
Systems  (DSS)  and  Management  Information  Systems  (MIS)  can 
greatly  enhance  the  quality  of  these  decisions. 

As  part  of  the  effort  to  improve  the  efficiency  and 
effectiveness  of  Air  Force  Civil  Engineering  units,  the  Air 
Force  is  introducing  the  Work  Information  Management  System 
(WIMS)  in  all  Base  Civil  Engineering  (BCE)  Squadrons  (15). 
These  systems  utilize  a  WANG  mini-computer  network  system  to 
support  application  software  developed  by  the  USAF.  RED 
HORSE  squadrons  have  been  the  target  of  similar  automation 


attempts,  but  with  less  success.  While  the  squadrons  have 
obtained  small  micro-computer  systems,  the  automation  re¬ 
quirements  of  these  squadrons  are  not  adequately  defined. 


Justification  for  Study 

RED  HORSE  Squadrons  have  a  different  mission  and 
operate  differently  from  Base  Civil  Engineering  Squadrons. 
Compared  with  the  BCE  squadrons,  RED  HORSE  squadrons  have 
little  experience  with  computers.  Prior  to  the  introduction 
of  WIMS,  most  BCE  squadrons  operated  wit n  8EAMS  (Base 
Engineer  Automated  Management  System).  Because  of  this,  the 
use  of  computers  in  BCE  squadrons  may  be  more  institutional¬ 
ized.  RED  HORSE  Squadrons,  on  the  other  hand,  have  not  used 
BEAMS.  They  have  relied  on  manual  information  systems  best 
characterized  by  bulky  files  and  wall  hung  "grease  boards". 

RED  HORSE  squadrons  implementing  computer  systems  must 
identify  and  design  useful  applications  before  the  intended 
benefits  and  objectives  of  any  automation  program  can  be 
realized.  This  thesis  research  effort  is  directed  towards 
helping  RED  HORSE  squadrons  develop  automation  applications 
by  examining  their  information  needs  and  providing 
recommendations  based  on  an  analysis  of  those  needs. 

Backg  round 

"RED  HORSE  squadrons  provide  a  highly  mobile,  rapidly 
deployable  civil  engineering  response  force  that  is  self- 
sufficient  for  limited  periods  of  time"  (17:6).  To  support 


wartime  and  peacetime  contingencies,  RED  HORSE  squadron 
personnel  and  equipment  resources  are  assigned  to 
specialized  mobility  teams.  The  composition  of  tnese  teams 
is  described  in  Air  Force  Regulation  93-9,  Civil  Engineering 
RED  HORSE  Squadrons .  During  peacetime,  tnese  squadrons 
conduct  specialized  personnel  training  in  various  areas, 
such  as  chemical  warfare,  Rapid  Runway  Repair  ( RRR ) , 
explosives  demolition,  special  weapons,  expedient  methods, 
and  security  training  (17:26-30).  Squadrons  also  conduct 
periodic  deployment  exercises  in  the  field.  Troop  training 
projects  provide  valuable  peacetime  proficiency  training 
for  the  craftsmen  assigned  to  the  squadron.  Personnel  are 
deployed  to  other  bases  to  do  construction  and  heavy  repair 
projects.  Because  of  these  activities,  the  environment  in 
the  squadron  is  characterized  by  a  constantly  fluctuating 
work  force,  as  people  and  equipment  move  from  one  project 
or  exercise  to  anotner.  To  accomplish  its  mission,  each 
squadron  is  divided  into  four  main  branches.  An 
organizational  chart  for  a  typical  RED  HORSE  squadron  is 
shown  in  Figure  1 . 

The  Engineering  Branch  contains  the  Engineering  Design 
and  Site  Development/Drafting  sections.  They  provide 
engineering  field  support;  conduct  field  surveys,  site 
selection,  and  base  layout;  and  perform  quality  control 
inspection  and  material  testing  (17:16). 


RED  HORSE  SQUADRON  ORGANIZATION 


Figure  1.  Organizational  Chart  (17:17) 

Tne  Logistics  Branch  contains  Vehicle  Maintenance, 
Supply,  Services,  and  Logistics  Plans  sections.  It  provides 
all  logistics  support,  including  maintenance  of  all  venicles 
and  equipment;  storage,  control,  and  issue  of  all  materials, 
clothing,  and  weapons;  operation  and  maintenance  of  field 
messing  and  laundry  services;  medical  care?  and  the 
preparation  and  maintenance  of  squadron  mobility  plans 
( 17:18-19)  . 


The  Operations  Branch  contains  the  Operations  Center, 
Cantonment  Flight  (vertical  skills)  and  Airfields  FLight 
(horizontal  skills).  Tne  Operations  Center  schedules  and 
monitors  all  RED  HORSE  work  projects  and  deployments.  The 
Cantonment  and  Airfields  Flights  provide  the  craftsmen  or 
workforce  to  accomplish  vertical  and  horizontal 
construction,  including  utility  systems,  paving,  well 
drilling,  and  explosive  demolition  operations  (17:17-18). 

The  Administrative  Branch  includes  the  Squadron  Section 
Commander,  First  Sergeant,  and  Squadron  Orderly  Room  func¬ 
tions.  It  provides  support  to  the  Commander  in  discipline, 
morale,  and  administration  of  squadron  personnel.  Other 
special  staff  functions  include  Resource  Management, 
Training,  and  the  Unit  Mobility  Center. 

Automation  Efforts .  Compared  to  BCE  squadrons,  whicn 
implemented  BEAMS  in  the  early  1970’s,  RED  HORSE  squadrons 
have  only  recently  shifted  their  interest  towara 
automation.  Early  efforts  were  mainly  focused  on 
administrative  functions  through  the  acquisition  of  word 
processing  equipment.  In  1984,  the  820th  and  823rd  RED 
HORSE  squadrons  received  Z-100  micro-computers  as  part  of  a 
Headquarters  Tactical  Air  Command  (HQ  TAC)  computer  buy. 
While  some  of  the  micro-computers  were  to  be  used  for 
mobility  applications,  such  as  load  planning,  the  squadrons 
were  left  to  develop  their  own  applications  for  the 
remainder  of  the  systems.  A  15  May  1985  RED  HORSE 


Information  Management  System  (RBIMS)  study,  conducted  oy 
the  Air  Force  Civil  engineering  and  Services  Center  (.42 
AF ESC),  stated  the  automation  requirement  tor  RED  HORSE 
squadrons : 

A  computer  system  with  interface  and  broadoand  network 
inclusive  of  all  RED  HORSE  squadrons,  deployed  loca¬ 
tions  and  sites.  Implementation  of  this  integrated 
information  management  system  for  resource 
allocations,  scheduling,  tracking  and  control  using 
CRT  terminals;  programmable  intelligent  terminals; 
sheet,  continuous  form,  and  portaole  printers; 
plotters;  and  minicomputers.  The  system  will  provide 
a  central  point  for  information  regarding  training; 
personnel  actions;  work  force  management  and 
assignments;  mobility  and  deployment  planning; 
administrative  management  of  squadron  activities;  wor* 
processing  and  control  to  include  tracing,  material 
processing,  gob  management  to  work  processing, 
tracking,  and  long  requirements  generation,  ana  design 
scheduling  and  analysis;  and  squadron  financial 
management.  This  system  will  provide  almost  total 
automation  of  the  critical  functions  of  a  civil  engi¬ 
neering  RED  HORSE  squadron  and  provide  management  with 
summary  data  on  the  operation  of  the  organization  to 
allow  identification  in  graphical  format  of  problem 
areas  and  inefficient  operations.  (6:1) 

During  October  and  November  19do,  tne  320th  and  aZi rd 
RED  HORSE  squadrons  each  received  a  WANG  V3-100  mini-comput¬ 
er  system  which  consisted  of  30  workstations,  one  central 
processing  unit,  two  174-megabyte  disk  drives,  one  75-mega¬ 
byte  disK  drive,  and  three  printers.  These  systems  were 
transferred  from  Air  Force  Regional  Civil  Engineer  (AFRCE) 
offices  by  the  Directorate  of  Information  Systems, 

H<2  AFESC/S I ,  as  a  result  of  AFRCE  hardware  upgrades.  These 
systems  were  valued  at  over  $200, QUu  each  (2b). 

Initial  telephone  interviews  with  several  Key  managers 
at  the  823rd  RED  HORSE  indicated  Little  support  for  the  new 


computer  system.  Some  concerns  voiced  were  as  follow:  "It 
will  costs  us  $30,000  a  year  to  maintain!",  "Is  tne  823rd 
ready  for  this  mucn  computer?"  "We  can  do  everything  our 
section  needs  on  a  Z-243."  "Can  we  justify  this  system?" 
Questions  concerning  the  plan  for  installing  the  system 
elicited  such  responses  as:  "Maybe  we  should  be  asking — Do 
we  want  to  ta*e  it  out  of  the  box?"  "It  may  not  be  to  late 
to  nip  this  [WANG  computer]  in  the  bud." 

These  concerns  may  reflect  limited  knowledge  and 
experience  of  squadron  personnel  with  automated  management 
systems  and  tneir  own  information  needs.  Since  the  system 
is  basically  a  "forced  implementation"  initiated  by  tne 
Major  Command  (MAJCOM),  Tactical  Air  Command  (TAC),  and  HQ 
AFESC ,  squadron  personnel  may  have  trouble  supporting  the 
implementation.  In  addition  very  little  direction  was 
provided  to  the  squadrons  to  implement  the  system  (5;  36). 

During  a  RED  HORSE  Commanders  Conference  in  April  1987, 
the  HQ  AFESC  Directorate  of  Readiness  and  the  RED  HORSE 
Squadrons  decided  to  postpone  the  implementation  of  the 
WANG  systems  and  proceed  with  the  development  of  application 
software  for  the  Z-100  and  Z-248  micro-computers  (7;  12; 

35).  The  203rd  CES(HR)  Air  National  Guard,  a  newly  formed 
unit,  was  designated  as  the  pilot  unit  for  RED  HORSE 
automation.  This  unit  was  selected  because  they  volunteered 
and  because  they  had  a  few  people  in  their  unit  who  were 
interested  in  personal  computers  (12;  35). 
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Proolem  Statement 


The  direction  RED  HokSE  automation  efforts  took  as  tne 
result  of  the  1987  RED  HORSE  Commanders  Conference  appears 
to  represent  a  wholesale  abandonment  of  the  concepts  estab¬ 
lished  in  the  1985  RHIMS  study.  If  the  RED  HORSE  automation 
program  is  designed  by  individuals  oriented  towards  personal 
(micro)  computers,  the  resulting  system  will  most  likely 
take  that  form.  Also,  if  the  system  is  designed  by  a  few 
individuals  with  limited  knowledge  of  the  information 
requirements  of  the  users  outside  their  own  section,  the 
resulting  system  may  not  be  well  integrated  for  total 
squadron  support.  This  approacn  raises  several  questions. 
Will  the  designers  understand  the  information  needs  of  all 
squadron  managers?  Will  their  system  design  satisfy  the 
automation  requirements  of  other  squadrons?  Finally,  will 
their  design  allow  for  system  growth  as  other  applications 
arise? 

The  1975  RHIMS  study  noted  several  problems  with  the 

existing  systems  based  on  micro-computers  and  nost  base 

automation  support.  According  to  the  study. 

Only  limited  procedures  are  available  to  produce  spe¬ 
cial  inquiries  or  reports  or  to  establish  application 
data  bases.  These  procedures  are  often  inadequate  due 
to  data  field  constraints,  lack  of  automated  editiny, 
and  the  need  to  use  a  nonuser  oriented  programming 
language  to  develop  application  reports.  Additionally 
terminals  are  limited  in  number  and  physical 
availability  discourages  user  involvement  in  the 
existing  system.  .  .  .  Our  present  method  of  using 
other  organizations'  automated  systems  allows  RED 
HORSE  to  automate  only  a  small  part  of  work 
requirements  and  is  not  state-of-the-art  nor  user 
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frienaly  if  it  is  available  at  all.  .  .  .  The 
current  system  being  used  by  RED  HORSE  is  not 
responsive  enough  to  functional  user  requirements  for 
information,  nor  is  it  flexible  enough  to  allow  user 
development  and  fine  tuning  of  information 
subsystems.  (6:2) 


It  is  not  clear  if  an  automated  system  based  on  stand-alone 
micro-computers  will  overcome  these  problems;  however,  the 
design  of  a  mini-computer  based  network  system  would  also 


pose  problems. 


If  RED  HORSE  squadrons  implement  an  automated 
management  system  based  on  the  WANG  computer,  they  will  be 
given  the  BCE  WIMS  software  to  select  the  application 
programs  they  can  use  or  modify.  It  will  be  the 
responsibility  of  each  RED  HORSE  squadron  to  develop  the 
balance  of  the  applications  to  meet  their  unique 
requirements  (14;  48).  This  would  be  a  difficult  task  for 
several  reasons.  First,  RED  HORSE  squadrons  lack  expertise 
in  working  with  computers,  since  their  only  prior  experience 
is  with  small  Zenith  Z-100  and  Z-248  micro-computers. 
Secondly,  the  small  numoer  of  RED  HORSE  squadrons  will  not 
get  the  cross-flow  of  ideas  and  applications  that  BCE 
organizations  will.  This  is  due  to  the  fact  that  there  are 
only  four  active  RED  HORSE  squadrons,  whereas  there  are 
over  100  BCE  squadrons  that  will  be  using  WIMS.  Finally, 
the  difference  in  the  RED  HORSE  mission  makes  it  difficult 
for  them  to  develop  specific  applications. 

A  BCE  squadron  has  fairly  standard  base  operating  and 
maintenance  responsibilities  that  require  specific  computer 
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applications  such  as  real  property,  utilities  management, 
military  family  housing,  and  contract  management.  RED 
HORSE  squadrons  do  not  nave  base  maintenance  responsibili¬ 
ties,  and  are  much  more  mobile.  They  spend  most  of  their 
time  training  for  their  wartime  mission,  either  in  garrison 
or  at  deployed  locations.  Thus,  they  may  not  be  able  to 
dedicate  personnel  to  the  development  of  applications. 

Their  people  may  simply  not  have  the  time,  due  to  deploy¬ 
ments  ana  exercises. 

The  primary  problem  seems  to  be  the  lacx  of  any  central 
policy,  based  on  a  detailed  analysis  of  user  needs,  to  guide 
the  development  of  automated  management  systems  for  RED 
HORSE  squadrons.  There  is  no  analysis  to  validate  the  early 
automation  program  decisions.  For  managers  in  tne  RED  HORSE 
squadrons,  the  management  questions  are — What  type  of 
system  do  we  need,  and  how  do  I  get  the  greatest  benefits 
from  it?  This  research  attempted  to  answer  these  questions 
and  provide  a  basis  for  future  policy  decisions  by 
identifying  user  requirements  through  data  collection  and 
analysis . 


Research  Objectives 

The  objectives  of  this  research  were  to  11]  identify 
areas  where  MIS/DSS  systems  should  be  applied,  [2]  provide 
recommendations  for  the  development  of  specific  DSS  appli¬ 
cations,  and  1 3  J  provide  recommendations  for  the  imple¬ 
mentation  and  long  term  development  of  these  systems. 


research  to  write  the  actual  software  for  the  MI3/0SS  appli 
cations,  but  to  identify  specific  applications  and  tne 
associated  system  capabilities  to  support  them. 


Due  to  time  constraints  and  the  difficulty  associated 
with  getting  information  from  overseas  bases,  only  two  CONU 
RED  HORSE  squadrons,  tne  820th  CES(HR)  and  823rd  CES(HR), 
were  considered  in  this  research.  The  focus  of  the 
applications  was  limited  to  the  peacetime  management 
activities  of  a  RED  HORSE  squadron,  and  did  not  address  the 
automation  needs  of  a  squadron  deployed  under  field 
conditions.  Despite  this  scope  limitation,  the 
methodologies  presented  in  this  research  can  be  used  to 
determine  those  needs. 


1  2 


II. 


Implementation  Methodolog ies 

Since  the  development  of  the  first  computer,  automated 
information  systems  have  oeen  evolving  from  larye  expensive 
systems  with  limited  utility,  to  smaller  inexpensive  sys¬ 
tems  with  powerful  applications  for  practicing  managers. 

The  earliest  Data  Processing  (DP)  systems  evolved  into 
Management  Information  systems  (MIS),  wnich  focused  on 
improving  the  efficiency  of  managers  (2;  42).  In  more 
recent  times,  information  systems  have  evolved  that  focus 
on  the  improved  effectiveness  of  decision  makers.  These 
systems  are  called  Decision  Support  Systems  (DSS).  Tne 
concept  of  Decision  Support  Systems  is  relatively  new. 
Indeed,  most  of  the  theory  associated  with  DSS  nas  occurred 
since  the  early  1970's  and  too  little  research  is 
available  to  offer  a  universally  accepted  prescription  for 
designing  and  implementing  these  systems. 

In  this  chapter,  the  current  literature  will  be 
reviewed  in  order  to  develop  a  methodology  for 
accomplishing  the  research  objectives.  First,  some 
differences  between  MIS  and  DSS  and  their  development 
processes  will  be  examined.  Next,  different  analysis 
methodologies  will  be  discussed  to  provide  a  basis  for 
data  collection  and  analysis.  Finally,  various 
considerations  for  system  implementation  will  be  reviewed 


to  guide  the  recommendations  for  the  long  term  development 
of  RED  HORSE  automation  systems. 

MIS  versus  DSS 

According  to  Menkus,  Management  Information  Systems 
"are  those  [systemsj  that  drive  the  organization;  they 
carry  out  its  basic  f unct ions--f unds  accounting,  production 
control,  and  the  like"  (30:32).  The  primary  focus  of  MIS 
is  on  information  flows,  structured  tasks  and  decisions, 
improving  manager's  efficiency,  and  data  inquiry  and  report 
generation  (28:1,2;  42:7).  DSS,  on  the  other  hand,  are 
"interactive  computer-based  systems  that  help  decision 
makers  utilize  data  and  models  to  solve  unstructured 
problems"  (42:4).  A  DSS  combines  a  dialog  component,  which 
provides  the  user-interface;  a  memory  component,  which 
includes  a  data  base;  and  a  modeling  component  that 
provides  the  analytical  capabilities  for  problem  solving 
(42:260,301 ) . 

The  primary  focus  of  DSS  is  on  decisions,  semi- 
structured  and  unstructured  tasks,  improving  the 
effectiveness  of  managers,  and  user-initiated  and  user- 
controlled  models  that  help  conceptualize  the  problem  or 
decision  (28:2;  42:7).  DSS  may  use  information  provided  in 
an  MIS  (30:32),  and  are  generally  regarded  as  representing 
"a  natural  evolution  in  computer  applications"  (28:2). 


MIS  System  Development  Process 

According  to  Alexander  (1:12o-128),  tne  systems 
development  process  can  be  divided  into  three  phases:  the 
systems  analysis  phase,  the  design  phase,  ana  the 
implementation  phase.  In  the  systems  analysis  phase,  a 
detailed  description  of  the  system  is  developed  to  allow 
the  analyst  to  "examine  its  individual  segments  and 
understand  thoroughly  the  reasons  behind  any  peculiarities 
he  may  find"  (1:127).  This  descriptive  model  is  developed 
using  many  information  sources  such  as  policy  and 
procedures  manuals,  organization  cnarts,  and  personal 
interviews  with  managers  and  subordinates  in  the 
organizational  units. 

In  the  design  phase,  the  descriptive  model  is  usea  to 
identify  deficiencies  in  the  existing  system.  A  normative 
model  is  then  developed  to  overcome  these  deficiencies. 

The  final  phase  is  the  implementation  of  the  new 
system.  In  this  phase,  the  specifications  for  the  new 
system  are  developed  and  put  into  action  by  an 
implementation  plan  which  sets  fortn  the  activities  and 
individuals  responsible  for  accomplishing  them.  This 
includes  the  development  and  testing  of  computer  programs, 
training  for  tne  people  who  will  use  the  system,  and 
periodic  evaluations  to  control  tne  overall  implementation 


program. 
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DSS  System  Development  Process 


The  development  approacn  tor  DSS  systems  is  similar  to 
that  for  MIS  systems  in  that  it  requires  a  description  of 
tne  current  system  as  a  starting  point  for  the  development 
of  the  new  system. 

Sprague  and  Carlson  (42)  recommend  a  four-phased 
development  process  that  assesses  user  needs  and  builds 
user  commitment  early  in  the  development  of  the  system,  ana 
provides  for  an  evolutionary  development  process  based  on 
the  implementation  of  a  specific  DSS. 

Phase  I ;  Preliminary  Study  and  Feasibility 
Assessment.  Surveys  and  interviews  with  key  managers  are 
used  "to  determine  the  extent  of  DSS-type  applications" 
and  "the  likelihood  that  these  needs  will  continue  or 
increase  in  the  future"  (42:67).  The  implementer  starts 
explaining  the  DSS  to  users  during  this  phase. 

Phase  II:  Developing  the  DSS  Environment.  Once  it 
has  been  determined  that  a  DSS  is  needed,  a  DSS  group  is 
formed  to  formulate  the  objectives,  manage  the  development 
effort,  and  help  users  "bring  the  technology  to  bear  on  his 
or  her  problems"  (42:64).  During  this  phase,  the  "minimal 
set  of  tools  [hardware  and  software]  and  data"  are  acquired 
to  start  the  first  DSS,  and  the  group  continues  to  build 
user  commitment  to  the  project. 

Phase  III:  Developing  the  Initial  Specif ic  DSS .  Dur¬ 
ing  this  phase,  the  DSS  group  works  with  users  to  identify 


a  need  "with  a  high  probability  of  early  observable 
benefits"  (42:68),  and  to  develop  a  specific  OSS  to  deal 


wi tn  this  need.  The  specific  DSS  supports  a  specific 
decision  or  a  specific  decision-making  process  (42:301). 

Tni s  initial  specific  DSS  is  upgraded  and  refined  to 
respond  to  users'  needs. 

Phase  IV:  Developi ng  a  Subsequent  Speci f i c  DSS .  Tnis 
final  phase  is  really  a  continuous  process  of  finding  new 
applications  and  developing  specific  DSS  to  deal  with  them. 
The  authors  note  that  this  "staged  development  approach 
leads  to  tne  development  of  a  DSS  generator  wnien  evolves 
from  the  process  of  building  several  specific  DSS"  (42:69). 

Keen  (28)  recommends  a  pre-design  cycle  to  help 
identify  the  decisions  that  may  benefit  from  decision 
support  and  to  introduce,  early  in  the  design  process, 
those  factors  such  as  user  commitment  and  resources  that 
will  affect  implementation.  This  pre-design  cycle,  as 
outlined  in  Figure  2,  nelps  to  select  areas  for  DSS  support 
and  to  define,  compare,  and  select  specific  design 
alternati ves. 

Perhaps  the  most  significant  difference  in  the  design 
of  MIS  and  DSS  systems  is  the  focus  of  the  design  effort. 
Whereas  MIS  design  is  a  process  oriented  approach  that 
focuses  on  the  inputs  and  outputs  of  the  system,  the  design 
of  a  DSS  must  be  process  independent  and  focus  on  what  the 
system  is  intended  to  do  (28:180). 
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Figure  2.  The  Pre-design  Cycle  (28:177) 

Decision  Type  and  Structure 

The  design  of  a  D3S  must  be  process  independent.  It 
must  be  built  in  the  context  of  tne  decision  and  tne  deci¬ 
sion  maker.  Keen  (2S:35-9b),  describes  a  framework  for 
analysis  of  decisions  that  allows  the  system  designer  to 
identify  those  decisions  that  are  better  suited  for  either 
MIS  or  DSS  support.  This  framework  is  based  on  two  uni¬ 
dimensional  taxonomies  developed  by  R.fsi.  Anthony  and  tl .  A . 

S imon  (28:81 ) . 


The  first  dimension  classifies  the  decision  in  tnree 
categories  with  respect  to  the  type  of  decisions  involved. 
The  first,  strategic  planning,  is  "the  process  of  deciding 
on  objectives  of  the  organization,  on  changes  in  these 
objectives,  on  the  resources  used  to  obtain  these  objec¬ 
tives,  and  on  the  politics  that  are  to  govern  acquisition, 
use,  and  disposition  of  resources"  (28:82).  The  second, 
management  control,  is  "the  process  by  which  managers 
assure  that  resources  are  obtained  and  used  effectively  and 
efficiently  in  the  accomplishment  of  tne  organization's 
objectives"  (28:82).  Finally,  operational  control  is  "tne 
process  of  assuring  that  specific  tasks  are  effectively  and 
efficiently  carried  out"  (28:82). 

The  second  dimension  classifies  decisions  by  the  level 
of  difficulty  or  to  the  extent  that  they  are  repetitive  and 
routine.  Structured  decisions  are  those  decisions  that  do 
not  require  a  manager  to  solve.  They  are  routine  to  the 
point  that  a  procedure  has  been  developed  to  handle  them. 
Clerical  personnel,  data  processing,  or  management  science 
models  are  best  used  here.  Unstructured  decisions  are 
those  hard  or  unusual  decisions  that  cannot  be  programmed 
and  require  some  degree  of  human  intuition  to  solve.  Semi- 
structured  decisions  are  those  decisions  that  are 
difficult  enough  to  require  some  system  support,  but  also 
require  some  judgment  and  intuition  on  the  part  of  the 
manager.  DSS  are  best  used  here. 


TYPE  OF 
DECISION 


MANAGEMENT  ACTIVITY 


Operational 

Control 

- 
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DSS 

Un¬ 

structured 

Human 

Intuition 

Figure  3.  A  Framework  for  Information  Systems  (28:87) 

MIS/DSS  Analysis  Techniques 

As  mentioned  previously,  the  starting  point  for  the 
development  of  a  DSS  is  a  descriptive  model  of  the 
existing  system.  Systems  analysis  techniques  are  used  to 
develop  the  descriptive  model. 

Systems  Analysis .  Systems  analysis  attempts  to  deter¬ 
mine  the  essential  nature  of  present  information  flows. 
"Documenting  them  estaolishes  a  conceptual  case  ooth  for 
tne  detailed  analysis  of  the  current  system  and  the  subse¬ 
quent  development  of  tne  improved  one"  (1:131).  According 
to  Sprague  and  Carlson,  "Systems  analysis  refers  to  the 
initial  steps,  which  include  1)  analyzing  the  existing 
activities  or  problem  area,  and  2)  defining  the  performance 
requirements  of  the  system  that  will  oe  applied  to  those 


According  to  Munro 


determining  the  information  each 


manager  needs"  is  "generally  recognized  to  oe  one  of  the 
most  difficult  phases  in  the  development  of  Management 
Information  Systems  (MIS)"  (33:34).  He  describes  two  sys¬ 
tems  analysis  techniques  for  analyzing  managers  information 
needs.  These  two  approaches,  data  analysis  and  decision 
analysis,  differ  as  to  their  focus.  As  their  names  sug¬ 
gest,  data  analysis  focuses  on  "an  analysis  and  improvement 
of  the  existing  flow  of  data  to  the  manager"  (33:35), 
whereas  "decision  analysis  primarily  involves  an  analysis 


DATA  ANALYSIS  DECISION  ANALYSIS 


1.  Examine  all  reports, 

files  and  other  information 
sources  drawn  upon  by  the 
manager . 

2.  Discuss  with  the  manager 
the  use  of  each  piece  of 
information  examined. 


3.  Eliminate  unnecessary 
information. 


4.  Determine  unsatisfied 

information  needs  through 
interaction  with  tne 
manager . 


1.  Determine  major  decision 
responsibilities  through 
discussion  with  the 
manager . 

2.  Determine  policy  and 
organizational  objectives 
relevant  to  decision 
areas  identified. 

3.  Determine  specific  steps 
required  to  complete  each 
major  decision. 

4.  Develop  a  model 
(flowchart)  of 
each  decision. 

5.  Examine  flowchart  to 
determine  information 
required  at  each  step  in 
the  decision. 


of  decisions  made  oy  the  manager,  the  objective  oeing  to 

determine  the  information  required  at  each  step  in  the 

decision  process"  (33:35).  The  elements  of  these  two 

methods  are  shown  in  Figure  4. 

Data  analysis  involves  an  extensive  examination  of  tne 

information  a  manager  uses,  as  well  as  interviews  with  the 

manager,  to  determine  the  manner  in  whicn  the  information 

is  used.  The  data  analysis  method, 

...  involves  analyzing  a  manager's  existing 
information  flow  to  determine  information  no  longer 
required,  information  to  be  continued,  and  new 
information  requirements.  Information  no  longer 
required  is  eliminated;  required  information  is 
provided  by  the  information  system  applications  where 
appropriate.  (33:35) 

Decision  analysis  is  based  primarily  on  interviews  witn  tne 
manager  to  determine  his  decision  responsibilities.  The 
decision  analysis  method 

...  involves  first  determining  the  major  decision 
responsibilities  of  the  manager,  and  the  appropriate 
organizational  policy  and  oojectives.  Next,  the 
manager  articulates  the  various  decision  steps  and  the 
information  used  at  each  step.  The  analyst  develops 
a  decision  flowchart  representing  the  decision  steps 
and  the  information  used  at  each  step.  The  manager 
and  the  analyst  then  refine  both  the  decision  process 
and  the  information  requirements.  The  revised 
decision  flowchart  constitutes  the  final  statement  of 
information  requirements  for  each  decision.  (33:3b) 

According  to  the  author,  the  method  used  will  depend  on  tne 
situation.  Generally,  data  analysis  is  best  used  "where 
the  decision-making  is  well-understood,  routine  and  repeti¬ 
tive"  and  decision  analysis  is  best  used  "where  the  deci¬ 
sion-making  is  poorly  understood,  less  routine  and  less 
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repetitive"  (33:3!#).  More  often  than  not,  the  analysis 
used  will  be  a  combination  of  the  two. 

Standard  systems  analysis  techniques  such  flowchartin 
are  useful  for  developing  the  descriptive  model.  However, 
these  techniques  are  inadequate  for  defining  the  perform¬ 
ance  requirements  of  a  DSS. 

ROMC  Approach.  Most  decision  makers  rely  on 
conceptualizations  of  tne  problem  or  decision  and  have 
trouble  describing  the  actual  decision  making  process 
(42:98).  Because  the  DSS  support  requirements  cannot  be 
adequately  defined  in  advance,  another  systems  analysis 
technique  was  developed  that  focuses  on  the  tnings  a  user 
needs  in  oraer  to  make  a  decision. 

The  approach  is  based  on  a  set  of  four  user-oriented 
entities:  Representations,  Operations,  Memory  Aids, 
and  Control  Mechanisms.  The  capabilities  of  a  DSS 
from  the  user's  point  of  view  derive  from  its  ability 
to  provide  representations  to  help  conceptualize  and 
communicate  the  problem  or  decision  situation, 
operations  to  analyze  and  manipulate  those 
representations,  memory  aids  to  assist  the  user  in 
linking  the  representations  and  operations,  and 
control  mechanisms  to  handle  and  use  the  entire 
system.  For  obvious  reasons  we  call  it  the  ROMC 
approach.  (42:96) 

This  process  independent  method  defines  tne  components  of 
the  specific  DSS  in  terms  of  "the  set  of  ROMC  required  by 
the  user  to  face  the  decision-making  and  problem  solving 
tasKs"  (42:116).  To  use  this  analysis,  the  decision  is 
first  examined  in  terms  of  the  intelligence,  design,  and 
choice  operations  used  in  decision  making.  This  model, 
developed  by  H.A.  Simon,  describes  these  operations: 


Intelligence:  Searcning  the  environment  for 

conditions  calling  for  decisions.  Raw  data  are 
obtained,  processed,  ana  examined  for  clues  tnat  may 
identify  proolems. 

Design:  Inventing,  developing,  and  analyzing  possible 

courses  of  action.  This  involves  processes  to 
understand  the  problem,  to  generate  solutions,  and  to 
test  solutions  for  feasibility. 

Cnoice:  Selecting  a  particular  course  of  action  from 

those  available.  A  choice  is  made  and  implemented. 
(42:26-27) 

Once  the  decision  is  divided  into  these  three  phases,  the 
representations,  operations,  memory  aids,  and  control 
mechanisms  required  to  support  these  activities  are 
determined . 

The  representations  "provide  a  context  in  whicn  the 
user  can  interpret  outputs  and  invoke  the  operations" 
(42:102).  These  representations  are  what  the  user  sees: 
the  interface  between  the  system  and  the  decision  maker. 
They  may  take  on  many  forms  such  as  lists,  graphs,  reports, 
and  data  entry  forms  (42:102-103). 

The  operations  provided  by  the  system  perform  the  data 
manipulations  to  create  information.  Operations  "may 
involve  complicated  decision  aids,  such  as  simulation 
models  or  forecasting  algorithms"  or  simply  selecting 
subsets  of  data  or  generating  statistics  (42:104). 

Memory  aids  "support  the  representations  and 


operations"  by  providing  data  bases,  workspace , and 
libraries  for  "accumulating  results  or  the  operations  on 
the  representations"  (42:104-105). 


Finally,  the  control  mechanisms  provided  by  the  sys¬ 
tem  "facilitate  the  mechanics  of  using  the  system.  Exam¬ 
ples  are  menus  or  function  keys  for  operation  selections" 
(42:106)  and  other  features  which  help  the  decision  maker 
use  the  system.  The  specific  set  of  Representations, 
Operations,  Memory  Aids,  and  Control  Mechanisms  make  up  the 
specific  DSS  (42:11o). 

DSS  Development  Tactics 

The  design  of  Decision  Support  Systems  is  an 
evolutionary  process.  The  system  is  constantly  modified 
and  improved  as  the  user's  decision  support  requirements 
change.  The  development  of  a  DSS  represents  a  considera¬ 
ble  investment  of  both  time  and  resources.  Organizations 
must  decide  on  the  level  of  detailed  planning  and  inte¬ 
gration  they  will  put  into  the  development  of  the  DSS.  The 
more  planning  detail,  the  more  it  will  cost  and  the  longer 
it  will  take  to  develop.  On  the  other  hand,  without 
adequate  planning  and  integration,  the  useful  applications 
of  the  system  may  be  limited.  The  system  may  oe  too 
inflexible  to  accommodate  other  applications  as  they  arise. 
Sprague  and  Carlson  describe  three  general  approaches  to 
the  development  of  DSS: 

1 .  The  Quick-Hit.  This  approach  requires  the  least 
development  time  and  effort,  and  is  best  used  when  "there 
is  an  immediate  problem  area  but  no  evidence  of  long  term 
need"  (42:60-61).  The  organization  purchases  or  develops  a 


specific  system  to  "capture  tne  benefits,  tnen  considers 


wnat  to  do  next"  (42:60).  The  resulting  system  is  a 


specific  DS3,  or  "tne  hardware/software  that  allow  a 


specific  decision  maker  or  group  of  them  to  deal  with 


specific  sets  of  real  problems"  (42:10).  Tnis  approach  is 


the  fastest  way  to  develop  a  specific  DSS,  but  is  least 


flexible  in  adapting  to  otner  applications  that  may 


develop. 


2.  Tne  Staged  Development  Approach.  Some  amount  of 


advanced  planning  is  invested  in  the  development  of  a 


specific  DSS.  An  iterative  design  process  is  used  to 


incorporate  new  applications  while  "giving  a  somewhat  early 


payoff  through  the  completion  of  one  specific  DSS"  (42:61). 


This  approach  requires  more  time  and  investment  than  the 


"quick-hit"  approach,  but  is  more  flexible  and  leads  to  the 


accumulation  of  a  general  DSS  Generator  capability.  A  DSS 


Generator  "is  a  package  of  related  hardware  and  software 


which  provides  a  set  of  capabilities  to  build  specific  DSS 


quickly  and  easily"  (42:11). 


3 .  The  Complete  DSS .  This  approach  requires  exten¬ 


sive  development  time  and  investment,  since  a  completely 


integrated  DSS  Generator  is  developed  before  any  specific 


DSS  is  built  (42:61).  This  approach  may  take  years  to 


develop,  but  the  resulting  system  will  be  better  integrated 


to  support  many  applications.  It  is,  however,  very 


susceptible  to  technological  obsolescence  due  to  its  long 


development  time, 


Implementation 

Equally  important  to  the  design  of  a  MIS  or  DSS  is  it 

implementation.  Even  the  best  systems  are  useless  if  they 

are  not  used  by  the  people  they  are  designed  to  support. 

Multinovich  and  Vlahovich  define  implementation  as  a 

process  that  "entails  bringing  a  system  or  subsystem  into 

operational  use  and  turning  it  over  to  the  users"  (32:3). 

They  feel  implementation  should  be  a  part  of  the  "total 

system  design  effort,  which  begins  with  systems  analysis 

and  concludes  witn  testing  phases"  (32:8). 

Keen  and  Morton  note  that  successful  implementation 

strategies  may  be  applied  to  ooth  MIS  and  DSS,  out  the 

implementation  of  a  successful  DSS  may  require  more 

effort.  They  state  that, 

...  for  a  system  tnat  automates  a  well-aefined 
procedure  with  few  organizational  interdependencies, 
design  is  the  key  issue;  for  a  DSS,  whicn  explicitly 
focuses  on  management  processes  and  which  aims  at 
changing  procedures  and  concepts,  implementation  may 
be  far  more  complex  than  tne  formal  design  process. 
(28:139) 

Factors  Affecting  Successful  Implementation. 

According  to  Keen  and  Morton,  past  researchers  nave  had 
great  difficulty  interpreting  patterns  of  success  or 
failure  in  system  implementation  case  studies.  However, 
they  concluded  that  the  presence  of  the  following  factors 
increased  the  likelihood  of  success: 


1.  Top  management  support. 

2.  A  clear  felt  need  by  the  client. 


3.  An  immediate,  visible  problem  to  worx  on. 

4.  Early  commitment  by  the  user  and  conscious  staff 
involvement . 

5.  A  well-institutionalized  0R/MI3  or  MIS  group. 
(28:196) 

Alter' s  research  on  system  implementation  led  nim  to 
conclude  that  "the  likelihood  of  successful  implementation 
increases  to  the  extent  to  which  the  user  has  initiated  tne 
system  and  participated  in  its  development"  (2:154). 

Strategies  for  Successful  MI 3/DS5  Implementation. 

Alter  recommends  an  implementation  strategy  based  on  a  risk 
assessment  of  the  current  implementation  environment. 

This  method  consists  of  identifying  the  differences 
between  the  existing  situation  ana  "an  ideal  implementation 
situation.  Deviations  between  the  existing  circumstances 
and  the  ideal  are  identified  as  risk  factors"  and  an 
implementation  strategy  or  "course  of  corrective  action"  is 
developed  to  handle  each  deviation  (2:155,158). 

Alter  describes  this  ideal  implementation  situation 
as  one  which  allows  the  implementation  process  to  "be 
planned  and  controlled  with  maximum  certainty"  (2:157). 
Under  this  ideal  situation. 


the  system  is  to  be  produced  by  a  single  implementer 
for  a  single  user  who  anticipates  using  the  system  for 
a  very  definite  purpose  that  can  be  specified  in 
advance  with  great  precision.  Including  the  person 
who  will  maintain  it,  all  parties  affected  by  the 
system  understand  and  accept  in  advance  its  impact  on 
them.  All  parties  have  prior  experience  with  this 
type  of  system,  the  system  receives  adequate  support, 
and  its  technical  aesign  is  feasible  and  cost- 
effective  .  (2:157) 


Multinov ich  and  Vlahovich  recommend  some  people  ana 


system  related  strategies  to  oe  consiaered  daring  tne 
implementation  process  (See  Figure  6). 

Getting  management  involved  with  tne  implementation 
process  is  important  oecause  management  must  approve  the 
resource  expenditures  required  to  develop  and  implement  the 
system.  They  motivate  subordinates  to  provide  support  to 


People  Related  Strategies 

Get  Management  Involvea 

Ascertain  That  There  is  a  Felt  Need  for  the  System 

Get  User  Involvement 

Provide  Training  and  Education 

Consider  User  Requirements 

Consider  User  Attitudes 

Estadish  Effective  Communication 

Keep  Interface  Simple 

Let  Management  Determine  Information  Usefulness 

System  Related  Strategies 

Identify  the  Proolem 
Plan  the  Implementation 
Control  the  Implementation  Process 
Do  Post  Implementation  Evaluation 


tne  implementation  process,  ana  tney  can  affect 
interdepartmental  coordination  and  cooperation  (32:9). 
People  will  not  use  the  system  unless  they  feel  it  meets 
their  needs  and  is  useful  to  them.  The  authors  recommend 
implementers  work  with  users  to  "sell  them  the  system"  by 
helping  them  identify  problems  suited  for  system  support, 
getting  users  involved  in  the  system  design  and  by 
explaining  the  benefits  of  the  system  in  terms  of  what  it 
can  do  for  them  (32:11). 

Training  programs  should  include  "educating  the  user 
in  the  overall  purpose  of  the  system:  what  it  is  supposed 
to  do,  how  does  it  do  it,  why  do  we  want  or  need  it  done, 
and  who  must  do  it"  (32:10). 

Implementers  must  consider  user  requirements  such  as 
"flexibility,  simplicity,  reliability,  economy,  accuracy, 
compatibility,  security,  etc."  (32:11),  in  order  to  provid 
a  system  that  meets  the  users'  needs.  The  authors  state 
that,  "a  new  system  should  satisfy  a  particular  user's 
requirements  without  adversely  affecting  the  information 
requirements  of  other  users  in  the  system"  (32:11).  This 
might  be  provided  through  the  use  of  reports,  tailored  to 
the  specific  individual,  that  draw  data  from  a  master 
database.  The  implementer  must  also  consider  the  future 
plans  of  the  organization  and  the  possibility  for  future 
expansion  of  automated  applications  to  avoid  having  the 
organization  outgrow  the  system  and  face  the  cost  of 
implementing  a  new  or  larger  computer  system  (32:11). 


Failure  to  consider  user  attitudes  towards  tne  system 
can  greatly  reduce  the  success  of  the  implementation  and 
the  effectiveness  of  the  system.  Once  user  attitudes  are 
recognized,  the  strategies  for  getting  user  involvement  and 
providing  training  can  be  used  to  influence  those 
attitudes . 

Establisning  effective  communication  between  the 
implementers ,  management,  and  the  system  users  is  essential 
during  the  implementation  process.  The  communication 
process  should  be  analyzed,  and  "if  necessary,  the 
organizational  design  adjusted  to  increase"  user 
involvement  (32:12).  Keeping  the  interface  simple  is 
another  strategy  that  will  increase  the  acceptance  of  the 
system.  To  the  user,  the  interface  is  the  system.  It 
"must  be  kept  simple  so  as  not  to  scare  or  confuse  the 
user"  (32:13).  Also,  the  information  produced  oy  the 
system  must  be  useful  and  important  to  the  user  or  tne 
system  will  not  be  accepted.  The  usefulness  of  this 
information  must  be  determined  by  the  user--not  the 
designer  or  implementer  (32:13). 

Tne  system  related  strategies  shown  in  Figure  5  can  be 
summarized  as  (1)  determining  the  right  applications  for 
the  system  to  support,  (2)  planning  the  implementation 
early  on  to  ensure  compatibility  with  the  systems  design, 

(3)  controlling  the  implementation  by  setting  goals  and 
measuring  performance  through  systematic  reviews,  and 


(4)  evaluating  the  implementation  based  on  "a  prior 
definition  of  improvement"  to  determine  if  "system 
modifications  should  be  made"  and  "when  the  system  is 
complete"  (32:15). 


oumuiari 


In  this  chapter,  differences  between  MIS  and  DS3  were 
examined,  and  various  systems  analysis  methodologies  were 
presented  for  designing  effective  MIS  and  DSS  applications. 
This  literature  indicates  that  an  analysis  of  the  users' 
decisions  and  information  needs  provides  a  starting  point 
for  the  design  of  both  types  of  systems.  Systems  analysis 
techniques  that  focus  on  information  inputs  and  outputs  are 
better  suited  for  the  MIS  design  process.  Systems  analysis 
techniques  that  are  process  independent,  such  as  the  ROMC 
approach,  focus  on  the  decision  maker  and  his  decision¬ 
making  requirements  and  are  better  suited  for  DSS  design. 

Finally,  the  implementation  strategies  provided  in  the 
current  literature  offer  the  implementer  some  techniques  to 
increase  the  effectiveness  and  acceptance  of  the  resulting 
systems.  The  techniques  discussed  in  this  chapter  will 
now  be  used  to  develop  methodologies  for  accomplishing  the 
objectives  of  this  research  effort. 


According  to  Keen,  "the  first  step  in  design  is  to 
select  the  right  problem  to  work  on"  (28:167).  The 
identification  of  potential  MI3/DSS  application  areas 
followed  these  steps: 

Identify  Key  Decision  Makers.  A  review  of  policy 
guidance  (such  as  AFR  93-9  and  TAC  Regulation  85-3, 
Management  of  Training  Proiects,  Civil  Engineering  RED  HORSE 


Squadron ) ,  organization  charts,  handbooks,  and  telephone  and 
personal  interviews  witn  squadron  personnel  were  used  to 
identify  the  key  decision  makers  and  their  critical 
decisions  and  information  needs.  The  data  and  decision 
analysis  tecnniques  described  by  Munro  (33)  were  used  to 
summarize  the  specific  information  requirements  into  a 
table  which  indicated  the  organizational  sections  that 
supplied  the  information  and  tnose  that  used  the 
information.  Typical  decisions  made  by  managers  in  each 
section  were  arranged  in  a  decision  matrix  based  on  the 
framework  developed  by  Anthony  and  Simon  (28:81-96).  This 
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decision  matrix  classified  the  various  decisions  ucorai nj 


to  tnei r  decree  of  structure  (unstructured,  semi -st r uet ire i , 
and  structured)  and  tne  level  of  management  (strati-jic 
planning,  management  control,  and  operational  control)  at 
which  they  were  made.  The  results  of  each  analysis  were 
forwarded  to  each  RED  HORSE  squadron  for  validation. 

Determi ni ng  Proolems  wi tn  Current  Processes .  Inter¬ 
views  witn  squadron  personnel  were  used  to  determine  prob¬ 
lems  with  the  current  information  and  decision  processes. 
These  problems  are  summarized  by  each  section  in  Chapter  5. 
Tnese  problems  and  the  data  and  decision  analysis  results 
were  used  to  determine  which  applications  were  better  suited 
for  MIS  and  whicn  were  best  suited  for  DSS. 

Recommendati ons  for  Development  of  Spec i f i c  DSS 

Tne  decision  matrix,  described  aoove,  and  interviews 
with  key  managers  provided  several  critical  decisions  which 
were  used  to  determine  tne  required  system  capabilities. 

Descr i pti ve  Models .  Information  obtained  from 
regulations  and  interviews  was  used  to  develop  a  de¬ 
scriptive  model  of  these  critical  information  and  decision 
process.  This  step  paralleled  the  first  step  in  the  pre¬ 
design  cycle--"Moni tor  and  describe  the  current  decision 
process" — as  described  by  Keen  (28:174).  Information  ana 
decision  processes  flow  across  organizational  boundaries 
(Figure  6)  in  a  complex  system  of  information 
interdependencies.  Figure  6  represents  this  system  as  a 


Venn  diagram.  In  tms  organizational  system,  information 
generated  by  one  section  may  be  used  by  another.  Also, 
decisions  made  by  one  manager  may  affect  managers  in  otner 
sections.  The  descriptive  models  will  be  used  to  explore 
tnese  relationships. 
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Figure  6.  Venn  Diagram  of  Organizational  Boundaries 

Develop  Normative  Models .  In  this  stage,  more 
detailed  interviews  with  key  managers  provided  information 
that  described  how  the  information  and  decision  processes 
should  work.  Problem  areas  were  identified  by  comparing  the 
descriptive  and  normative  models.  Potential  DSS 
application  areas  were  selected  from  problem  areas 
associated  with  semi-structured  and  unstructured  decisions. 


Required  DSS  Capaoil ities .  To  answer  this  research 
question,  key  decisions  in  each  appiication  area  were 
analyzed  in  terms  of  the  intelligence,  design,  and  choice 
activities  performed  by  the  decision  maner.  The  ROMC 
approach  was  used  to  define  the  DSS  capaoilities  required 
to  support  these  decision  activities.  This  was  accomplisneo 
oy  identifying  the  required  Representations,  Operations, 
Memory  aids,  and  Control  mechanisms  corresponding  to  each  of 
the  intelligence,  design,  and  choice  activities,  as 
recommended  by  Sprague  and  Carlson  (42). 

Recommendations  for  System  Implementation 

Recommendations  for  implementing  the  above  DSS 
applications  were  obtained  from  answers  to  the  last 
research  question:  What  factors  will  affect  the 
implementation  of  the  system? 

A  simplified  risk  assessment  was  performed  to  identify 
potential  proolems  in  the  implementation  process. 

Strategies  for  overcoming  these  problems  were  developed 
based  on  strategies  documented  in  the  current  literature, 
modified  to  fit  the  RED  HORSE  squadron  environment. 


36 


•|  t.i  <.i  1,1  i| 


Iv.  Findings 


This  chapter  presents  the  findings  that  resulted  from 
the  research  methodology  outlined  in  Chapter  i.  Key 
managers  in  tne  RED  HORSE  squadron  were  identified  from  AFR 
93-9,  Civil  Engineering  RED  HORSE  Squadrons  (17)  and 
interviews  with  RED  HORSE  Commanders  and  branch  chiefs. 

These  interviews  were  conducted  using  the  interview 
questions  listed  in  Appendix  A.  Critical  activities, 
typical  decisions,  and  information  needs  were  determined 
from  personal  and  telephone  interviews,  and  from  a  review 
of  policy  guidance,  operating  handbooks,  and  other 
materials.  These  findings  will  be  presented  for  the  command 
section,  special  staff,  and  each  brancn. 


Command  Section 

According  to  AFR  93-9,  the  major  responsibilities  of 
the  command  section  are  to  "exercise  command  jurisdiction 
and  control  over  the  mission  accomplishment  of  the  squadron 
during  training,  exercises,  deployments,  and  other  mission 
activities";  to  ensure  compliance  with  higher  headquarters 
directives;  and  to  direct  and  control  "activities  related 
to  the  logistics,  engineering,  operations,  and  administra¬ 
tive  branches,  the  special  staff,  and  any  PDUs  (Permanently 
Detached  Units)"  (17:16). 


Commander . 


Interviews  with  commanders  indicated  tneir 


primary  decisions  to  be  those  dealing  with  allocating 
squadron  resources  to  competing  project  priorities  and 
assessing  organizational  performance  (12;  29). 

It  was  noted  tnat  the  current  information  management 
system  does  not  provide  a  consistent  way  to  display  squadron 
performance  in  various  areas  such  as  project  design  and 
construction  updates  or  the  status  of  personnel,  equipment, 
ano  financial  resources  (12).  Although  commanders  were  not 
interested  in  the  detailed  information  of  activities  witnin 
each  section,  they  felt  tney  needed  the  status  of  project 
scheduling  and  design,  materials,  funding,  and  equipment  to 
ensure  both  the  host  bases  and  the  squadron  were  ready  to 
support  the  project  deployment,  allowing  projects  to  proceed 
on  schedule  and  squadron  personnel  to  be  employed 
productively.  During  deployments,  commanders  need  actual 
versus  scheduled  progress  information  to  make  decisions 
involving  the  scneduling  of  training  exercises  and  other 
projects.  Some  typical  decisions  for  commanders  are 
presented  in  Appendix  C,  Key  Decision  Matrix.  The 
commanders '  specific  information  needs  are  presented  in 
Appendix  B,  Data  Analysis  of  Information  Needs. 

Deputy  Commanaer .  The  Deputy  Commander  assists  the 
Commander  with  many  daily  management  control  activities. 
Information  needs  for  these  managers  are  similar  to  those  of 
the  Commander  and  include  more  detailed  information  on 


project  status  and  scheduling  to  determine  when  to  halt 


projects  and  return  personnel  for  squadron  home  station 
training  in  a  manner  to  cause  least  impact  to  the  project 
schedule  and  host  base  (41).  Squadron  training  information 
is  also  required  to  ensure  personnel  are  trained  and  combat 
readiness  is  not  degraded.  Since  project  deployments  often 
cause  conflicts  with  training  appointments,  squadrons  neea  a 
way  of  integrating  project  schedules  with  training  sched¬ 
ules.  Typical  decisions  for  deputy  commanders  are  presented 
in  Appendix  C.  Their  specific  information  needs  are 
presented  in  Appendix  Q. 

According  to  LtCol  William  Schaal,  823rd  CES(riR)  Deputy 
Commander,  the  current  information  system  presents  several 
problems.  Accurate  and  current  cost  of  projects 
accomplished  by  the  squadron  are  difficult  to  determine  due 
to  the  manual  procedures  for  accounting  for  material 
expenditures,  credits,  TOY,  and  labor  costs.  Also,  similar 
information  provided  by  different  sections  aoes  not  agree. 
For  example,  venicle  status  information  provided  by  the 
Operations  Center  does  not  agree  with  that  provided  by  the 
Vehicle  Maintenance  section.  Finally,  frequent  changes  in 
the  project  design  and  construction  schedule  maxe  it  hard  to 
get  accurate  and  current  information  on  the  status  of 
programs  and  resources  (41). 
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Operations  Branch 

This  Drancn  is  primarily  concerned  witn  tne  execution 
of  the  Troop  Training  Program;  maintaining  special 
construction  capabilities  such  as  explosives  demolition, 
well  drilling,  and  asphalt  paving;  and  the  training  and 
assignment  of  branch  personnel  on  the  squadron's  mobility 
teams.  Key  managers  in  this  brancn  are  the  Director  of 
Operations  (DO),  Chief  of  Cantonment  Flight  (DOS),  Chief  of 
Airfields  Flight  (DOP),  and  the  Chief  of  tne  Operations 
Center  ( D00 ) . 

Interviews  witn  various  individuals  in  this  branch 
indicated  some  specific  decisions  and  questions  facing  these 
managers.  These  are  presented  in  Appendix  C.  Typical 
decisions  made  by  the  managers  in  this  branch  can  be  classi¬ 
fied  as 

(1)  Project  Scheduling  -  Which  projects  can  we  do? 
When  and  in  what  order?  These  are  decisions  made 
jointly  by  DO,  D00,  DOS,  ana  DOP  (13;  39;  40). 

(2)  Personnel  Scheduling  -  Who  will  we  send?  For  how 
long?  Should  we  return  this  individual  to  the 
squadron  or  re-deploy  him  to  another  project 
location?  These  decisions  are  made  primarily  by 
DOS,  DOP,  and  D00  (13;  39;  40). 

(3)  equipment  Scheduling  -  How  will  we  allocate 
equipment  resources  to  competing  projects? 

These  decisions  are  made  primarily  by  DOP  and  DOS 
(3;  13;  40). 

Director  of  Operations.  The  primary  information 
needs  of  the  Director  of  Operations  were  determined  to  be 
project  scheduling  and  tracking,  personnel  and  training 
status,  equipment  availability,  and  branch  financial 
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management  information.  Key  decisions  involved  scheduling 
a  level  of  project  effort  that  provided  adequate 
proficiency  training  to  branch  personnel  without  over¬ 
tasking  individual  shops  (39;  40).  It  was  noted  that  the 
current  manual  information  system  did  not  provide  adequate 
information  to  allow  this  manager  to  assess  the  impact  of 
the  project  schedule  on  his  people,  their  training,  or  the 
squadron's  readiness  posture  (40). 

Chief ,  Cantonment  Flight .  The  Chief  of  Cantonments 
Flight  is  responsible  for  managing,  controlling,  and 
directing  130  men  in  various  shops.  His  primary 
information  needs  include  personnel  availability,  project 
requirements,  project  status,  and  training  status.  His  key 
decisions  involve  the  selection  of  individuals  for  project 
deployment  and  maintaining  the  required  training  and 
mobility  capability  for  personnel  assigned  to  his  sect-ion. 

The  existing  squadron  information  management  system 
makes  it  difficult  to  determine  the  individuals  required 
for  each  deployment  and  their  availability.  Project 
evaluations  from  DE  showing  the  manpower  and  equipment 
requirements  are  often  received  within  30  days  of  the 
scheduled  start  date  (45).  By  the  time  supervisors  can 
determine  who  is  available  and  formulate  crew  lists, 
individuals  deploying  receive  only  a  few  days  of  notice  for 
their  pending  deployment.  The  lack  of  advance  notice  for 
long  deployments  (e.c[.  three  months)  causes  personal 
problems  and  adversely  affects  unit  morale. 
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Finally,  personnel  deploying  on  a  project  must  oat- 
process  through  several  sections.  The  Training  Section 
determines  wnether  tne  individual  needs  training;  Logistic 
Plans  ensures  he  has  updated  shot  records  and  dog  tags; 
and  Unit  Administration  determines  whether  he  has  pending 
disciplinary  action,  personnel  actions,  performance  reports 
or  awards  he  must  complete.  If  conflicts  arise,  the  indi¬ 
vidual  may  not  be  deployed,  and  the  crew  list  may  be  re- 
accompl i sned . 

Cn i ef ,  Ai rf i elds  FI i qht .  The  decisions  and 
information  needs  of  tne  Chief  of  Airfields  Flight  are 
similar  to  that  of  the  Chief  of  Cantonment  Flight.  Inis 
manager  also  controls  the  squadron  vehicle  dispatch  and 
operator  care  function,  ana  requires  detailed  vehicle  and 
equipment  status  information  for  selecting  equipment  for 
project  deployments.  It  was  noted  that  the  high  level  of 
TDY  for  individuals  assigned  to  both  the  Cantonment  ana 
Airfields  Flights  caused  problems  in  meeting  Airman 
Performance  Reports  (APR)  and  award  suspenses  (3;  13). 

Also,  the  current  squadron  information  system  aid  not 
provide  adequate  personnel  information,  such  as  leave 
projections  and  training  status,  to  assist  managers  in 
matching  personnel  available  with  project  requirements 
(  13)  . 

Chief,  Operati ons  Center.  The  Operations  Center  chief 
interfaces  with  OE  for  project  design  status  and  to  deter- 
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mine  manpower  and  equipment  requirements  based  on  the  pro¬ 
ject  evaluation  accomplished  by  DE 1 s  project  engineers. 

He  also  needs  vehicle  and  equipment  status  wnicn  ne  gets 
from  LGT  and  DOP,  personnel  availability  information  from 
DOS  and  DOP,  and  status  of  materials  for  local  projects  and 
work  orders  from  LGS.  He  maintains  shop  labor  accounting 
information,  and  provides  project  cost  information  to  F'l . 
Interviews  with  Operations  Center  managers  indicated 
several  problems  with  the  existing  squadron  information 
system. 

The  current  manual  system  of  tracking  project  cost  and 
maintaining  man-hour  labor  accounting  is  very  time 
consuming,  and  accounts  for  a  large  portion  of  the 
Operations  Center's  daily  workload  (45;  47).  This  section 
currently  uses  micro-computer  based  spreadsheets  to 
maintain  the  In-house  Work  Plan  (IWP),  but  labor  accounting 
and  work  scheduling  is  still  manually  accompl isned .  Also, 
the  Operations  Center  provides  reports  indicating 
personnel  TDY.  This  information  is  also  collected  and 
maintained  by  LGX  and  DA,  out  is  in  different  formats  and 
does  not  always  agree  (9;  45).  Finally,  changing  project 
priorities  and  project  delays  due  to  weather  or  problems 
with  host  base  support  cause  frequent  changes  in  tne 
squadron's  project  schedule.  The  existing  information 
management  system  is  too  slow  in  providing  accurate 
information  needed  to  evaluate  these  changes  in  terms  of 
the  manpower,  equipment,  and  resources  required. 


Logistics  Branch 


A  review  of  regulations  and  interviews  with  squadron 
personnel  indicate  the  key  managers  in  tnis  branch  are  the 
Director  of  Logistics  (LG),  the  Chief  of  Logistic  Plans 
( LGX ) ,  the  Chief  of  Supply  ( LGS )  ,  and  the  Chief  of  Vehicle 
Maintenance  (LGT).  These  managers'  decisions  ana  decision¬ 
making  information  needs  are  presented  in  detail  in 
Appendices  C  and  B  respectively,  and  are  summarized  below: 

(1)  Logistics  Management  -  What  equipment  do  we  need? 
Are  we  efficiently  managing  our  material 
resources?  Do  we  have  adequate  material  and 
equipment  stocks?  These  decisions  are  made  by 
all  sections  in  this  branch. 

(2)  Readiness  Management  -  Can  this  squadron  support 

the  tasking  indicated  in  this  mobility  plan? 

What  is  our  current  readiness  rating?  Is  this 
individual  available  for  deployment?  These  deci¬ 
sions  are  made  primarily  by  LGX  and  LG. 

Interviews  with  branch  personnel  indicated  some  typical 

decision-making  information  needs  and  problems  wich  tne 

current  information  systems. 

Director  of  Logistics.  The  LG's  primary  information 
needs  are  vehicle  and  equipment  status  from  LGT,  equipment 
requirements  from  D00,  funding  and  supply  status 
information  from  FM  and  LGS,  and  mobility  status 
information  from  LGX.  This  information  is  used  to  mane 
decisions  involving  the  day-to-day  management  of  the 
branch . 

Chief  of  Logistic  Plans .  Critical  decisions  involved 
the  determination  of  the  squadron's  mobility  readiness, 
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ana  tne  configuration  of  personnel  and  equipment  increments 
for  deployment.  Information  needs  were  training  status 
from  OT;  personnel  status  from  DA  ana  D00;  mobility  team 
assignments  from  all  squadron  sections;  and  equipment  and 
cargo  data  from  all  sections  such  as  weight,  cube,  loaa 
lists,  and  transport  restrictions  (16;  36). 

It  was  noted  that  the  current  micro-computer  based 
load  planning  system  used  by  LGX  does  not  provide  a 
reliable  product  that  i nai cates  how  the  mobility  increments 
should  be  configured  for  various  aircraft  types.  They  feel 
a  need  for  a  computer  assisted  load  planning  system  that 
allows  them  "to  snift  increments  around  and  generate  a 
modified  load  plan"  (9).  Also,  information  used  by  LGX  is 
quite  fragmented.  They  receive  training  information  (such 
as  individual  skill  ana  special  capability  training),  from 
OT,  but  schedule  and  maintain  mobility  training  such  as 
pallet  build-up,  cargo  courier,  and  hazardous  cargo 
training  themselves  (16;  36). 

Chi ef  of  Supply .  The  Chief  of  Supply's  primary 
decisions  involve  the  management  of  squadron  materials  to 
support  the  operation  of  the  squadron,  the  accompl i shment 
of  projects  and  cantonment  maintenance  work,  and  mobility 
training  and  deployment  exercises;  and  the  management  of 
funds  used  to  acquire  these  materials. 

Interviews  with  these  managers  indicate  a  major  prob¬ 
lem  in  the  lack  of  integration  between  the  squadron  and  the 
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host  BCE  and  case  supply  automated  information  systems  that 
support  the  RED  HORSE  squadron.  According  to  CMS gt  Robert 
Dycus,  Chief  of  Supply  for  the  620th  RED  HORSE,  the  lacK  of 
such  an  interface  with  the  BCE  Government  Owned  Civil 
Engineering  Supply  Store  (GOCESS)  means  that  RED  HORSE 
material  requisitions  must  be  delivered  to  the  host  BCE 
for  input  into  their  Civil  Engineering  Material  Acquisition 
System  (CEMAS).  One  individual  from  tne  820tn's  Supply 
Section  works  in  tne  BCE  to  assist  with  these  inputs. 
However,  material  destined  for  the  82l)th  is  delivered  to 
tne  BCE  material  holding  area  to  allow  CEMAS  information  to 
be  updated,  and  must  be  reloaded  and  trucked  five  miles  by 
tne  82Uth  for  their  use.  In  addition  to  this  extra 
handling  and  wasted  man-hours,  materials  are  difficult  to 
locate  and  may  be  inadvertently  pulled  by  BCE  personnel  for 
use  on  their  projects  (20). 

The  lack  of  an  automated  interface  makes  it  extremely 
difficult  to  make  inquiries  on  the  status  of  materials 
ordered,  and  the  cost  of  all  materials  for  each  project  or 
work  order  (20;  43).  Another  problem  noted  was  mobility 
bag  inventories.  The  nigh  level  of  deployment  exercise 
activity  in  RED  HORSE  squadrons  makes  inventories  difficult 
to  maintain.  Bags  are  physically  inventoried  when  drawn 
and  returned,  and  an  inventory  card  i r  placed  in  each  oag 
with  a  copy  in  a  central  file.  Shortages  of  mobility  bag 
items  are  determined  by  manually  reviewing  each  card  and 


totaling  the  result  for  each  item.  Managers  in  both 
squadrons  notea  tne  difficulty  in  determininq  which  bags 
were  missing  a  certain  size  clotning  item  (20;  4i). 

Chi ef  of  vehi cle  Mai ntenance.  The  Chief  of  Vehicle 
Maintenance  makes  decisions  involving  the  daily  management 
of  the  RED  HORSE  vehicle  and  equipment  fleet.  These 
managers  need  information  from  the  operations  branch 
indicating  what  equipment  is  required  for  each  project, 
where  it  is  going,  when  it  is  required  and  for  how  long 
(21;  31;  44).  They  interface  with  D00  to  determine 
requirements  for,  and  the  maintenance  status  of,  equipment 
and  vehicles  deployed  on  training  projects.  They  also 
provide  LGX  with  fleet  status,  including  Estimated  Time  In 
Commission  (ETIC)  for  equipment  out  of  commission. 

It  was  notea  that  tne  squadron's  current  information 
management  system  did  not  always  provide  a  list  of 
deploying  vehicles  in  time  for  this  section  to  adequately 
inspect  and  complete  repairs  and  scheduled  maintenance 
prior  to  departure  (44).  Project  scheduling  information 
could  help  these  managers  select  mechanics  to  deploy  on 
projects,  make  better  budget  forecasts,  and  develop 
personnel  leave  scnedules  (44).  Also,  fuel  consumption 
data  is  required  for  each  deployed  vehicle  to  allow  their 
Vehicle  Information  Management  System  (VIMS)  to  compute 
vehicle  mileage  and  generate  the  corresponding  scheduled 
maintenance  requirements.  Fuel  consumption  information  is 


not  always  received  for  deployed  vehicles.  upon  return, 
when  this  information  is  input  to  VIMS,  many  vehicles  are 
reported  as  overdue  scheduled  maintenance  (44). 


The  current  squadron  information  system  does  not 
provide  an  automated  means  of  monitoring  the  status  of 
parts  ordered  through  the  Contractor  Operated  Parts  Store 
(COPARS).  iMuch  time  and  effort  is  expended  conducting 
physical  inventories  to  determine  the  COPARS  performance 
and  parts  availability  (31).  The  difficulty  in  determining 
parts  status  makes  it  hard  for  Maintenance  Control  to 
assign  realistic  ETIC  to  vehicles  in  maintenance.  Finally, 
there  is  no  means  available  for  capturing  and  analyzing 
historical  information  to  determine  parts  consumption  rates 
or  to  estimate  required  stock  levels  for  War  Readiness 
Spares  Kit  (WRSK)  (44). 

Engineering  Branch 

Key  managers  in  this  branch  are  the  Direccor  of 
Engineering  (DE),  Chief  of  the  Design  Section  (DEE),  and 
the  individual  Project  Engineers  (PE)  assigned  to  specific 
projects.  Typical  decisions  made  by  the  managers  in  this 
branch  can  be  classified  as 

(1)  Project  Design  and  Planning  -  Which  projects  can 
we  design?  When  and  in  what  order?  These  are 
decisions  made  jointly  by  DE,  DO,  CD,  and  CC. 

Wnat  major  activities  must  be  accomplished?  What 
manpower  and  equipment  will  be  required?  How 
much  will  it  cost?  These  decisions  are  made  by 
the  individual  PE's  and  DE. 


(2)  Personnel  Scheduling  -  Who  should  I  assign  as  PS? 
What  is  my  design  schedule?  These  decisions  are 
made  Oy  DE  from  inputs  by  DEE. 

Pi  rector  of  Eng i neer i nq .  The  DE  jointly  wi tn  DO,  CD 
and  CC  review  project  requests  to  determine  their  training 
value  and  feasibility  for  RED  HORSE  accompl » shment .  The 
DE  needs  design  status  from  DEE,  DEP,  and  the  PE's  to 
develop  and  maintain  design  schedules  and  present  this 
status  to  the  Commander  and  his  staff  in  weexly  project 
update  briefings.  Interviews  with  these  managers  indicated 
several  problems  of  concern. 

Pernaps  tne  biggest  problems  facing  these  managers  are 
tne  changing  project  priorities,  delays  in  project  designs 
accomplished  by  host  bases,  and  frequent  changes  in  tne 
squadron's  project  schedule  due  to  short  notice  exercise 
and  project  taskings  by  the  Numbered  Air  Forces  and  MAJCOM. 
The  existing  information  management  system  is  too  slow  in 
providing  accurate  information  needed  to  plan,  design,  and 
evaluate  these  changes  in  terms  of  the  manpower,  equipment, 
and  resources  required,  or  to  develop  and  maintain  design 
schedules  ( 4 ;  11). 

Another  problem  is  the  inability  to  collect  and  use 
historical  project  design  and  construction  performance  and 
cost  data.  Without  this  data,  actual  unfunded  planning  and 
design  cost  for  each  project  is  currently  estimated  with 
little  or  no  certainty  (4).  Historical  performance  and 
cost  data  would  help  improve  the  speed  and  accuracy  of 
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project  manpower,  equipment,  and  cost  evaluations  ana 
allow  the  development  of  unit  cost  estimates  for  various 
types  of  facilities  such  as  roads  and  pre-engineered 
buildings  to  be  used  by  other  agencies  considering  projects 
for  accomplishment  by  RED  HORSE  (4). 

Chief ,  Design  Section.  Information  needs  for  the 
Chief  of  Design  are  essentially  the  same  as  for  the 
Director  of  Engineering.  Key  decisions  involve  the 
development  and  maintenance  of  the  squadron  in-house  design 
schedule  (11;  38).  Again,  changing  project  priorities, 
project  delays,  and  short  notice  taskings  make  it  difficult 
to  maintain  an  effective  design  schedule  (38). 

Pro ject  Engineer .  Key  information  needs  for  the 
Project  Engineer  are  project  design  status,  construction 
status,  and  the  availability  of  manpower  ana  equipment  with 
which  to  plan  the  project's  accomplishment.  It  was  noted 
that  project  evaluations  are  time  consuming  and  difficult 
to  accomplish  accurately  due  to  insufficient  cost 
information.  Also,  the  project  evaluations  must  be 
reaccomplished  if  the  project  is  scheduled  well  beyond  the 
original  estimated  start  date.  Construction  activity 
charts  (CPM  and  PERT)  used  to  plan  project  activities  are 
time  consuming  and  usually  lack  the  format  or  level  of 
detail  for  making  effective  resource  allocation  decisions. 
Since  they  are  manually  constructed,  they  cannot  be  updated 
quickly  for  use  in  evaluating  changes  in  a  project's 
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schedule.  This  limits  their  usefulness  to  managers  ootn  in 
the  squadron  and  in  the  field  (11;  40;  45). 

Administrative  Branca 

According  to  policy  regulations  and  interviews  with 
squadron  personnel,  the  key  managers  in  this  section  are 
the  Squadron  Section  Commander  (CCJ),  the  Squadron  first 
Sergeant  (CCF),  and  the  Cnief  of  Administration  (DA)  (7:16; 
25).  Tnese  managers'  decisions  ana  decision-making  in¬ 
formation  needs  are  presented  in  detail  in  Appendices  C  and 
fl  respectively,  and  are  summarized  below: 

( 1  )  Personnel  Management  -  Is  the  squadron 

sufficiently  manned?  Should  this  individual  be 
retained  or  allowed  to  re-enlist? 

(2)  Unit  Administration  -  Are  we  meeting  suspenses 
for  performance  reports,  awards  and  decorations, 
and  correspondence? 

Squadron  Section  Comma nde r .  Squadron  Section 
Commanders  support  the  Commander  "in  controlling  squadron 
discipline,  morale,  welfare,  and  mission  performance" 
(17:1t»).  They  neea  personnel  data  maintained  by  the 
orderly  room.  Unit  Career  Advisor,  and  Unit  Administration 
to  provide  recommendations  to  the  Commander  and  section 
supervisors  regarding  discipline  and  retention  of  squadron 
personnel  ( 25 ) . 

Squadron  First  Sergeant.  Information  needs  for  First 
Sergeants  are  similar  to  those  for  the  Squadron  Section 
Commander.  These  managers  require  easy  access  to 
individual  personnel  records. 


Chief  of  Administration.  These  managers  monitor  the 


status  of  personnel  actions,  review  and  revision  of 
squadron  publications  and  policy  letters,  travel  orders, 
and  suspenses  for  correspondence,  performance  reports,  and 
awards.  They  also  monitor  squadron  administrative  worn 
loads  and  the  use  of  word  processing  equipment  (22;  34). 

Funds  Management 

According  to  AFR  93-y,  the  Funds  Manager  "monitors 
squadron  fund  expenditures,  recommends  fund  allocations, 
and  coordinates  preparation  of  unit  budget"  (17:16).  The 
Funds  Managers'  decisions  and  decision-making  information 
needs  are  presented  in  detail  in  Appendix  C  ana  Appendix  B 
respectively,  and  are  summarized  as: 

(1)  Financial  Management  -  Do  sections  have 
sufficient  funds  to  accomplish  their  mission? 

(2)  Budget  Formulation  -  vVhat  are  our  funding 

requirements? 

The  Funds  Manager  interfaces  witn  managers  of  eacn  branch 
and  special  staff  to  receive  budget  requests,  and  to 
monitor  and  adjust  quarterly  fund  targets  for  each  section. 
They  also  work  closely  with  the  Operations  Center  in 
monitoring  project  cost  chargeaole  to  squadron  Operating 
and  Maintenance  funds  (24;  27).  They  interface  with  the 
supporting  host  base  Accounting  and  Finance  Office,  from 
whom  they  receive  fund  status  information.  They  also 
receive  reports  from  the  host  Base  Supply  indicating  fund 
expenditures  and  status  of  contracts  (24;  27).  Interviews 

with  these  managers  indicated  several  problems  of  concern. 
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According  to  MSgt  Hall,  Funds  Manager  for  the  323rd 
RED  HORSE,  project  cost  accounting  is  his  oiggest  problem 
area.  "The  [current  squadron  information  managementj 
system  does  not  provide  a  systematic  flow  of  information  to 
tell  how  we  are  aoing  in  regards  to  project  cost  control" 
(27).  He  monitors  the  cost  of  all  projects  accomplished  by 
the  d23ra  and  must  get  labor  hours  spent  from  D00,  and  cost 
of  materials  received  from  LGS  for  cantonment  projects. 

For  projects  at  deployed  locations,  he  depends  on  labor 
costs  reported  from  the  deployed  project  manager  through 
D00,  and  material  costs  reported  by  the  BCE  at  tne  deployed 
location  (18:4).  As  it  may  take  weeks  or  months  for  this 
information  to  reacn  the  squadron,  current  ana  accurate 
cost  status  for  projects  is  nearly  impossible  to  determine 
and  frequent  requests  for  additional  funds  must  be  made 
(24;  27). 

TSgt  Folle,  Funds  Manager  for  the  320tn  RED  HORSE  also 
feels  project  costing  is  a  problem.  While  their  Operations 
Center  (D00)  performs  most  of  the  project  cost  accounting 
functions,  the  funds  manager  monitors  project  costs 
associated  with  training  that  are  chargeable  to  the  820th. 
Information  needed  to  monitor  project  costs  comes  from  many 
sources  and  is  not  centralized,  making  it  hard  to  track 
project  cost  (24).  He  feels  his  biggest  problem  is  "trying 
to  clarify  section's  funding  needs"  (24).  Branches  don't 
provide  budget  requirements  clearly  or  in  sufficient 


detail,  and  project  costs  estimates  are  not  accurate  (24; 
27).  The  current  squadron  information  management  system 
does  not  provide  a  means  for  forecasting  fund  requirements 
based  on  the  project  schedule. 

The  amount  of  squadron  funds  required  for  TD*  travel 
and  materials  is  directly  related  to  the  level  of  project 
construction  effort.  When  tne  squadron's  project  schedule 
changes,  the  type  and  amount  of  funds  required  to  support 
that  schedule  changes.  These  managers  need  a  way  to 
forecast  the  funds  required  to  support  tne  changing  project 
schedule  to  allow  them  to  initiate  corrective  actions 
sooner  and  avoid  constant  reprog  ramming  actions  (24;  27). 
Also,  funds  managers  expressed  a  need  for  an  automated 
information  system  that  provides  an  interface  with  host 
base  functions  such  as  Accounting  and  Finance,  Base  Supply, 
Base  Contracting,  and  Base  Civil  Engineering;  as  well  as 
the  capability  to  make  forecasts  and  present  information  in 
graphs  (sucn  as  pie,  bar  or  line  charts),  for  use  in 
briefings  to  the  Commander  and  his  staff  (24;  27). 

Training 

The  key  manager  in  this  section  is  the  Chief  of 
Training  (OT)  (10;  17:16;  46).  His  typical  decisions  are 
associated  with: 

(1)  Training  Scheduling  -  Who  needs  training,  wnat 
type,  and  when?  Who  is  available  to  fill  this 
training  quota? 
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(2)  Training  Monitoring  and  Reporting  -  What  percent 
of  oar  people  have  completed  required  training? 

Is  this  individual  making  satisfactory  On  the  Joo 
Training  (OJT)  progress? 

Managers  in  ttiis  section  wor<  closely  with  the 
mobility  plans  section  and  rely  on  them  to  identify 
specific  individual  training  needs  for  personnel  assigned 
to  the  various  squadron  mobility  teams.  They  need 
information  from  many  sources  to  effectively  schedule 
personnel  for  training.  They  need  information  from  DA  ana 
the  section  supervisors  that  indicate  which  people  are 
available  for  training,  and  information  from  000  that 
indicates  when  personnel  deployed  are  scheduled  to  return 
to  the  squadron  (10;  46).  They  also  interface  with  the 
MAJCOM  and  nost  base  activities  to  request  training  quotas 


(10;  17:16) . 

Their  biggest  problems  deal  with  scheduling 
individuals  for  training.  Information  on  personnel 
availability  for  training  is  fragmented,  and  changes  in  the 
squadron's  project  schedule  make  it  difficult  to  develop  a 
meaningful  training  schedule.  Personnel  scheduled  for 
training  are  often  pulled  for  deployment  on  high  priority 
projects,  or  delays  in  project  accomplishment  delay 
individuals  returning  to  the  squadron  for  training.  The 
result  is  a  high  rate  of  missed  appointments  (10;  46).  The 
Training  Section  can  determine  which  individuals  need 
training,  but  supervisors  are  often  reluctant  to  allow  the 


individual  to  be  scheduled  because  of  uncertainty  as  to 
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and  when  that  individual  will  oe  needed  for  a  particular 
project. 


Unit  Safety  Office 

The  Squadron  Safety  Manager's  decisions  are  generally 
semi-structured  or  structured.  His  primary  information 
needs  are  for  personnel  and  equipment  information  required 
to  accomplish  accident  and  ground  mishap  reports.  Safety 
Managers  maintain  inspection  records  ana  suspense  status 
for  safety  reports.  They  also  analyzes  historical  accident 
data  to  predict  accident  trends  and  to  make  aecisions 
regarding  the  type  of  accident  prevention  programs  required 
in  tne  squadron.  One  manager  uses  his  nome  computer  to 
analyze  data  due  to  the  lack  of  automated  support  in  the 
squadron  ( 3 ) . 

Summary 

Although  many  sections  were  acquiring  and  developing 
applications  for  Z-100,  and  Z-243  micro-computers,  tne 
programs  and  formats  differed  between  tne  sections,  making 
it  difficult  to  share  information.  Information  exchange 
was  primarily  through  oral  briefings  and  reports  generated 
by  the  collecting  section. 

Detailed  and  voluminous  information  on  projects, 
personnel,  and  training  for  these  400-man  squadrons 
frequently  caused  managers  to  suffer  from  information 
overload.  The  squadron's  current  information  systems  Jo 


not  provide  a  fast,  reliable  fLow  of  information  oet^een 
sections.  This  creates  an  environment  wnere  most 
management  decisions  are  made  under  conditions  of 
uncertainty,  even  though  tne  information  is  generally 
available  in  the  organization. 


V.  ANALYSIS 


This  chapter  presents  the  analysis  that  resulted  from 
the  research  methodology  outlined  in  chapter  3.  This 
chapter  will  describe  the  different  analysis  techniques  used 
i.n  this  research.  The  conclusions  drawn  from  these  analyses 
will  be  presented  in  the  next  chapter. 

Decision  Analysis 

Interviews  with  managers  in  the  RED  HORSE  squadrons 
indicated  some  of  the  typical  decisions  facing  these 
managers  and  provided  valuable  insight  as  to  their  decision 
making  information  needs.  The  decisions  were  arranged  in  a 
decision  matrix  based  on  the  taxonomy  developed  by  Antnony 
and  Simon  (2d:8 1).  The  matrix  classified  each  decision  as 
to  the  degree  of  structure  and  tne  level  of  management  at 
whi.cn  tne  decision  is  made.  This  analysis  was  used  to 
identify  tnose  unstructured  ana  semi-structured  decisions 
tnat  could  best  De  supported  by  a  DS3  as  well  as  tne 
structured  decisions  tnat  lend  tnemselves  to  MIS  support. 
This  analysis  was  also  used  to  determine  specific 
information  needs  of  tne  various  managers  in  tne  RED  HORSE 
squadron.  Tne  results  of  this  analysis  are  presented  in 
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Data  Analysis 

Managers  m  eacn  section  were  interviewed  co  determine 
their  essential  decision-making  information  needs.  These 
information  needs  were  grouped  into  19  areas  of  related 
information  and  arranged  in  a  table  that  indicated  the 
sections  that  used  the  information  and  those  sections  that 
provided  the  information.  The  results  of  an  initial  data 
analysis  were  forwarded  to  ooth  squadrons  for  validation. 
Managers  in  the  squadrons  generally  agreed  with  the  results, 
but  occasionally  disagreed  whether  a  specific  information 
item  was  required,  or  whether  they  provided  the  information 
or  simply  used  it.  Such  conflicts  were  resolved  by  listing 
the  information  item  as  being  used  oy  the  manager.  This 
analysis  is  presented  in  detail  in  Appendix  b,  but  is 
summarized  in  Table  1  to  indicate  the  types  of  information 
shared  most  often  between  the  various  sections  in  the 
squadron. 

Using  the  data  analysis  in  Appendix  B,  the  number  of 
information  elements  used  in  each  information  type  was 
divided  by  the  total  number  of  information  elements  of  that 
type  to  compute  the  percentage  of  information  elements  used 
by  type  for  each  manager.  Taole  1  indicates  the  areas  where 
managers  use  50  percent  or  more  of  the  information  elements 
in  each  information  type.  This  table  helps  the  reader 
visualize  the  relationships  of  various  information  types  to 
the  managers  by  indicating  the  heavy  users  of  each 
information  type. 
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Table  1.  Summary  Results  of  Daca  Analysis 


TYPE  OF  INFORMATION  SECTIONS 


C 

c 

D 

D 

0 

D 

L 

L 

L 

L 

L 

D 

D 

0 

s 

D 

r • 

0 

R 

C 

D 

0 

0 

0 

0 

G 

G 

G 

G 

r • 
o 

E 

E 

E 

E 

A 

c 

T 

M 

0 

s 

p 

X 

T 

s 

F 

£ 

p 

w 

Project  Tracking 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Project  Design 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Project  Planning 
and  Evaluation 

X 

X 

X 

X 

X 

X 

X 

X 

Project  Cost 

X 

X 

X 

X 

Equipment/Vehicles 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Maintenance  Supply 

X 

X 

Supply  Equipment 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

A 

X 

X 

X 

Supply  Clothing 

X 

X 

WR3K/WRM  Mgt 

X 

X 

X 

Supply  Requisitions 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Tool  Issue 

X 

X 

X 

X 

Residual  Materials 

X 

X 

X 

X 

X 

X 

Mobility/Readiness 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Financial  Mgt 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Individual  Personnel 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Personnel  Mgt 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Administration 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Training 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Hazard/Mishaps 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X  indicates  the  manager  uses  50  percent  or  more  of  tne 
information  elements  in  this  type. 


The  results  also  indicate  a  strong  need  for  sharing 
information  between  different  sections.  The  degree  to  which 


information  is  snared  between  sections  was  determined  by 
totaling  the  number  of  sections  using  or  providing  each 
information  element  and  averaging  the  totals  for  each 
information  type.  Table  2  lists  the  ranking  of  information 
types  in  order  of  increasing  users. 


Table  2.  Ranking  of  Information  Shared  by  Sections 


RANK 

INFORMATION  TYPE 

RANK 

INFORMATION  Tf PE 

1  . 

Individual  Personnel/ 

10. 

Hazard/Mishaps 

Financial  Management 

1  1  . 

Equipment/Venicle 

2. 

Training  Status 

Management 

3. 

Administration 

12. 

Project  Planning 
and  Evaluation 

4. 

Mobility/ Readiness 

13. 

Residual  Material 

5. 

Project  Tracking 

14. 

Project  Cost 

6. 

Supply  Equipment 

1  3  . 

Tool  Issue 

7. 

Project  Design 

1  6 . 

WRSK  Mgt 

8. 

Supply  Requisition 

17. 

Supply  Clothing 

9. 

Personnel 

Administration 

la. 

Maintenance  Supply 

Descriptive  Model 

The  findings  generated  by  this  research  indicate  two 
major  activities  of  the  squadron:  (1)  Accomplishing  troop 
training  projects,  and  (2)  maintaining  a  combat  engineering 
deployment  capability.  This  section  will  begin  with  the 
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development  of  a  descriptive  model  that  indicates  key 
decision  making  processes  associated  with  these  activities. 
In  the  next  section,  a  normative  model  is  developed  to 
identify  decision-making  processes  that  could  be  improved 
through  automation.  Figures  7  through  12  describe  the 
descriptive  model  for  project  program  execution. 

To  maintain  proficiency  in  their  wartime  engineering 
skills,  RED  HORSE  squadrons  accomplish  construction  and 
heavy  repair  projects  for  other  bases.  Various  oases  sena 
their  project  requests  to  the  RED  HORSE  squadron  through 
their  parent  MAJCOM  and  HQ  AFESC  (17:31).  These  requests 
are  reviewed  by  the  RED  HORSE  Commander,  Deputy  Commander, 
and  the  Operations  and  Engineering  managers  to  determine 
whether  the  project  is  feasible  and  provides  valuaole 
training  (Figure  7).  If  accepted,  tne  project  is  logged 
into  the  Operations  Center  ( D00 )  and  forwarded  to  the 
Engineering  Branch  (DE)  for  evaluation. 

The  DE  assigns  a  Project  Engineer  (PE)  to  manage  the 
design  and  evaluation  eftort  (Figure  b).  The  PE  performs  a 
pre-design  evaluation  of  the  project  to  estimate  tne 
manpower,  equipment,  materials,  and  funds  required  to 
accomplish  the  project  (18:2).  This  information  is  provided 
to  the  Operations  Branch  to  allow  the  project  to  be 
initially  scheduled  in  the  troop  training  project  schedule. 
The  PE  also  serves  as  the  primary  point  of  contact  with  the 
host  base  to  ensure  the  required  host  base  material,  design, 
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and  funding  are  provided  to  support  the  project.  The  DE 
reviews  the  project's  scope  in  more  detail  and  decides 
whether  tne  project  shoulo  oe  designed  oy  the  requesting  BCE 
or  by  RED  HORSE,  based  on  his  in-house  design  scnedule  an a 
his  section's  projected  tasking  (4;  11). 


Figure  7.  Receipt  and  Review  of  Project  Requests 

Upon  the  completion  of  the  project  design,  the  PE 
performs  another  project  evaluation  which  is  based  on  a 
detailed  Bill  of  Materials  (BOM)  and  a  Critical  Path  Method 
(CPM)  analysis  of  tne  manpower  and  equipment  that  will  be 
required  during  construction.  The  PE  must  check  with  the 
Airfields  Flight  (DOP)  to  see  if  RED  HORSE  equipment  will  oe 
available  to  support  the  project.  If  not,  he  calls  the  host 
base  at  the  project  location  to  get  information  on  the 
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availability  of  3CE  and  local  rental  equipment.  In  some 
cases,  it  may  be  cheaper  to  rent  equipment  locally  than  to 
transport  RED  HORSE  equipment.  Also,  mobility  requi rements 
affect  the  decision  of  whether  to  deploy  RED  HORSE  equipment 
and  vehicles.  The  PE  makes  a  detailed  estimate  of  the 
funded  and  unfunded  costs  based  on  the  travel,  per  diem,  and 
labor  cost  of  the  personnel  deploying;  the  cost  of 
materials;  the  operating  cost  and  depreciation  of  RED  HORSE 
equipment  to  be  deployed;  and  the  rental  costs  for  equipment 
that  will  be  obtained  at  the  project  location  (18:2).  Tne 
PE  drafts  a  list  of  men  and  equipment  required  for  eacn 
project,  indicating  personnel  required  by  Air  Force 
Specialty  Code  (AFSC)  and  equipment  required  by  type,  ana 
the  dates  required.  The  Dfi  forwards  the  project  evaluation 
package  to  the  Operations  Center  (D00). 

The  Operations  Center  updates  the  troop  training 
project  schedule  based  on  the  updated  project  evaluation. 
When  the  project  is  within  12  months  of  it's  estimated  start 
date  (ESD),  it  is  inserted  into  the  schedule  as  directed  by 
the  Commander  (45).  The  scheduler  inputs  the  project 
requirements  into  an  In-house  Work  Plan  (IWP)  spreadsheet  to 
check  the  feasibility  of  the  new  schedule  according  to 
manpower  and  equipment  availability.  Other  projects 
affected  by  the  schedule  change  are  rescheduled  as  directed 
by  the  Commander  until  a  feasible  project  schedule  is 
obtained.  Figure  9  describes  tne  project  scheduling 
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PROJECT  ENGINEER  (PE) 


Figure  8.  Project  Design  ana  Evaluation 


When  the  project's  ESD  is  within  one  month,  D00  will 
forward  tne  crew  lists  and  equipment  lists  to  the  Cantonment 
(DOS)  and  Airfields  (DOP)  flights  to  make  personnel  and 
equipment  assignments  to  crew  lists  indicating  the  specific 
names  and  AFSC's  of  personnel  selected  to  deploy. 
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Generally,  the  supervisor  makes  the  assignment  after 
consulting  with  an  assignment  board  on  the  shop  wall  to 
verity  that  the  individual  desired  is  available,  and  not 
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Figure  9.  Project  Scheduling 

scheduled  for  another  project  during  the  same  time  period 
(Figure  10).  The  supervisor  must  also  check  the  individual 
for  overdue  or  scheduled  training  and  appointments.  The 
vehicle  dispatch  section  in  DOP  uses  a  similar  method  to 
assign  equipment  by  type  and  registration  number.  The 
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bigure  1J.  Equipment  and  Personnel  Selection 


The  Project  Manager  (PM)  provides  a  list  of  deploying 
equipment  to  the  vehicle  maintenance  section  and  coordinates 
the  final  crew  list  with  other  squadron  sections.  The  PM 
coordinates  the  final  crew  list  with  the  Logistic  Plans 
Section  (LGX)  to  resolve  any  conflicts  with  scheduled 
mobility  training  and  to  ensure  each  member  on  the  deploying 
team  has  an  alternate  available  in  the  squadron  to  backfill 


his  .nobility  team  position.  For  example,  if  an  individual 
is  assigned  to  the  RH-1  mobility  team,  and  his  alternate  is 
not  available,  the  individual  cannot  deploy  and  the  crew 
list  must  be  reaccomplished.  The  Training  Section  (OD 
reviews  the  crew  list  to  determine  if  deploying  inoiviauaLs 
are  scheduled  for,  or  overdue,  individual  training 
requirements.  If  tnere  are  conflicts,  OT  attempts  to 
schedule  the  individual  for  training  prior  to  departure  or 
arrange  for  the  individual  to  receive  training  at  tne 
deployed  location.  This  is  extremely  difficult  to  do  on 
short  notice  and  may  cause  the  crew  list  to  be 
reaccomplished  to  replace  the  affected  individual.  The 
Director  of  Operations  reviews  the  equipment  ana  crew  lists 
to  ensure  they  are  complete,  that  they  do  not  conflict  witn 
other  resource  requirements  such  as  exercises  or  otner 
projects,  and  that  the  commitment  of  these  resources  will 
not  degraae  the  readiness  posture  of  tne  squadron.  This 
coordination  process  is  indicated  in  Figure  11. 

D00  and  the  PE  continue  to  monitor  project  status,  sjcn 
as  funding  and  material  support,  up  to  the  time  that  the 
crew  is  scheauled  to  deploy.  Normally,  materials  for 
projects  at  deployed  locations  are  ordered  ana  stored  oy  tne 
host  3CE.  Prior  to  the  team  deployment,  D00  contacts  the 
host  base  to  confirm  that  all  required  support  is  available. 
If  the  required  support  is  not  available,  such  as  100 
percent  materials  on  hand,  then  a  new  ESD  is  established  mi 


the  project  is  rescheduled.  Signit leant  leii/i  ;  1 

project’s  ESD  may  affect  personnel  and  e^npn.-r: 
availaoility .  In  sucn  cases,  the  personnel,  ana  ••-!.*..  ■•••  .* 
lists  must  be  revised  and  the  coordination  witn  ot:v*r 
sections  repeated  (Figure  12).  If  the  project  is 
supportable  by  the  host  base,  the  team's  personnel  anu 
equipment  are  prepared  for  deployment. 

The  DO  works  with  the  Project  Manager  to  decile  tv.- 
mode  of  transportation  for  the  deploying  crew  bu  o  >n  t  .  ■ 
project  needs  and  a  comparison  of  the  costs  of  travel  o, 
commercial  or  government  airlift  or  government,  renti.,  or 
private  vehicles.  The  Project  Manager  drafts  the  FDx 
orders,  coordinates  with  the  Funds  Manager  for  the  proper 
fund  cite,  and  delivers  them  to  DA  for  processing.  .<inen  a 
personnel  and  equipment  preparation  is  completed  t.ne  team 
deploys . 

During  tne  construction  phase,  the  deployed  Project 
Manager  tracks  labor  and  materials  expended  and  provides 
this  information  to  the  Operations  Center  during  weekly 
project  updates,  both  by  mail  and  by  telephone  (47).  If 
determined  that  additional  manpower  or  equipment  is 
required,  the  Project  Manger  makes  a  request  to  D00,  who 
coordinates  the  request  with  DOP  and  DOS,  and  th>  above 
process  is  repeated. 
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i'-t"  :  i  r  st  point,  in  tne  exeeation  of  tne  i  ED  HUrtSE  troop 
ti  lining  project  program  recommended  for  automated  support 
i  >  cn-  imji.i.-emj  lesign  unj  evaluation  process.  tiers,  an 
lit  j, nated  design  scnedulmg  module  (a  DS3  application)  coulu 
is  si  st  tne  oo  in  assi  jmn  j  engineers  to  the  various 
projects,  ind  m  developing  an  effective  design  scnedule, 
tnat  ;ouii  ue  easily  updates  as  project  priorities  change. 
Inis  nodule  could  provide  design  scheduling  and  status 
reports  (an  MIS  application)  to  the  various  squadron 
managers.  A  cost  estimating  module  could  draw  laoor  nours, 
and  materials  cost  data  from  a  historical  database  or  rrom 
Engineering  Performance  Standards  (EPS)  to  help  engineers  in 
performing  project  evaluations.  Anotner  D3S  application  is 
a  project  planning  module  that  wouLd  provide  automated 
project  management  support,  sued  as  Critical  Path  Method 
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(CPM)  and  Project  Evaluation  and  Review  Technique  (PERT),  to 
provide  a  visual  representation  of  the  manpower  and 
equipment  required  throughout  the  project  duration. 


The  next  point  in  the  project  evaluation  process  is 
recommending  equipment  to  be  deployed  by  RED  HORSE, 
equipment  to  be  provided  by  the  host  BCE,  and  rental 
equipment.  Here,  the  engineer  needs  a  list  of  RED  HORSE 
equipment  and  vehicles  projected  to  be  available  in  the 
timeframe  the  project  is  scheduled  for  accompl isnment .  This 
module  would  assist  the  engineer  in  selecting  RED  HORSE 
equipment  by  comparing  the  cost  of  deploying  squadron 
equipment  with  the  cost  of  renting  equipment  based  on  the 
transportation  distance  and  operating  hours  required.  This 
module  should  also  have  the  capability  to  project  fuel  and 
other  operating  costs  as  well  as  equipment  depreciation 
costs  from  data  in  an  equipment  database. 

The  initial  project  scheduling  process  also  lends 
itself  to  MIS  and  DSS  support.  Here  it  is  proposed  that  RED 
HORSE  squadrons  use  a  work  scheduling  module,  similar  to 
that  developed  for  the  BCE  WIM3  system.  Since  availability 
of  heavy  construction  equipment  severely  constrains  tne 
project  scheduling  decision,  the  module  should  generate 
recommended  project  schedules  based  on  both  manpower  and 
equipment  availability.  This  scheduling  module  would  allow 
alternative  project  schedules  to  be  evaluated  (3  DSS 
application)  and  provide  data  on  the  current  project 
schedule  to  all  squadron  sections  (an  MIS  appl icat 1  on ) . 
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The  current  process  of  evaluating  ana  scneduling 
projects  is  too  slow  to  react  to  changes  in  the  project 
schedule.  D00  often  receives  project  evaluations  within  one 
month  of  the  project  start  date.  It  has  been  suggested  that 
evaluations  should  be  completed  at  least  two  montns  prior  to 
the  project  start  to  allow  adequate  time  for  personnel  and 
equipment  preparation.  A  scheduling  module  could  improve 
the  current  process  by  reducing  the  time  required  to  develop 
new  project  schedules,  and  allowing  equipment  and  crew  lists 
to  be  developed  sooner.  The  Vehicle  Maintenance  Section 
could  get  advanced  information  regarding  equipment  scheduled 
to  deploy,  and  thus  would  have  adequate  time  to  inspect  and 
repair  them.  Individuals  would  get  more  advance  notice  of 
their  deployments,  allowing  them  to  complete  required 
training  and  personal  actions,  and  reduce  the  stress  imposed 
on  their  families  due  to  short  notice  TDYs . 

The  personnel  and  equipment  assignment  process  could 
also  oenefit  from  OSS  support.  Here  the  system  could 
support  managers  by  checking  individuals  assigned  to  a  crew 
list  against  master  training  and  personnel  dataoases  tor 
potential  conflicts  with  training,  appointments, 
administrative  actions,  and  other  considerations,  such  as 
leave  scnedules  and  time  away  from  station.  Moreover,  every 
piece  of  equipment  assigned  to  a  project  could  be  checked 
agjinst  i  master  equipment  ind  vein  ole  database  for 
scheduled  ma  mtenance 
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con  t  1  lets  w  i  t.’i 


and  other  project 


Coord  mat  ion  witn  tne  Funds  Management  Section  for 
funds  required  to  support  a  project  deployment  could  also  o e 
improved  tnrouqn  M1S/DSS  support.  Tne  current  sjuuuron 
information  systems  do  not  allow  tne  Funds  Manager  to  assess 
changes  in  funds  required  caused  oy  chanqes  in  the  level  of 
project  activity.  A  OSS  financial  forecestinq  module  is 
requireu.  This  nodule  would  use  project  cost  infer  nation 
provided  Dy  the  project  evaluations  to  determine  tnj  funds 
required  by  ELement  of  Expense  Investment  Code  (EEIC/  fur 
each  quarter,  based  on  the  current  project  schedule. 

Toe  final  point  in  the  process,  reschedul  inj,  cuulJ  be 
improved  tnrouqh  the  use  of  two  OSS  applications  mentioned 
previously.  First,  tne  operations  Center  coulu  use  tne  CtM 
information  provided  in  tne  project  planning  noujle  to 
evaluate  chanqes  in  a  project's  estimated  completion  date 
(ECO).  Deployed  project  managers  could  telephone  00.)  to 
report  chanqes  m  project  milestones  (e.^.  a  six  la*  del  ly 
in  pourinq  concrete  for  a  buildmq  foundation)  .  0J0 

personnel  could  access  tne  CPM  for  tnat  project,  cnanje  tne 
activity  start  times,  and  the  system  would  analyze  and 
report  new  nilestones  ana  project  completion  dates. 

Secondly,  000  could  use  the  schedulinq  module  to  evaluate 
chanqes  in  the  total  project  scnedule  caused  by  enunqes  m 
an  individual  project's  ECO. 

HOMC  Ana ly s i s .  Tne  descriptive  md  normative  model  , 
developed  above  and  typical  decisions  associated  witn  tnis 


process  (Appendix  C)  were  used  to  detjrmine  the  general 
system  requirements  fur  supporting  various  decisions. 

Several  critical  semi-structured  decisions  were  selected  for 
this  analysis.  These  are  listed  in  TaDle  3. 

TaDle  s .  decisions  Selected  for  ROMC  Analysis 

1.  Considering  the  affect  on  mooility  team  readiness, 
should  I  approve  this  project  schedule? 

2.  Can  we  design  this  project  In-house?  Who  snould  I 
assign  as  Project  Engineer?  How  should  I  assign 
engineers  to  this  design  effort? 

3.  How  should  we  distribute  squadron  ooligation 
authority?  What  are  our  quarterly  fund  requirements? 

4.  What  stock  levels  should  we  establish  for  our  War 
Readiness  Spares  Kits  (WRSK)? 

5.  Who  snould  I  assign  to  this  project  deployment? 

6.  Considering  that  possiole  changes  in  a  project  start 
date  may  cause  deployed  personnel  to  miss  scheduled 
training,  should  I  approve  this  project  crew  list? 

7.  Wnat  equipment  and  vehicles  snould  we  deploy?  Wnac 
vehicles  should  we  borrow  or  rent? 

6.  When  should  this  project  be  scheuuled? 

^ .  When  should  tms  training  be  conducted?  How  many 

training  quotas  do  I  neea?  Who  should  I  schedule  for 
this  training? 

First,  key  decisions  were  analyzed  in  terms  of  Simon's  tnree 
stages  of  dec  is ion-ma* ing  to  determine  the  Intelligence, 
Design,  and  Choice  activities  performed  by  the  decision 
maker.  Then,  the  detailed  Requirements,  Operations,  Memory 
aids,  and  Control  mechanisms  required  of  a  DSS  to  support 
those  activities  were  determined.  This  ROMC  analysis  is 


ratner  lengt.ny  ana  ii  included  in  Appendix  J,  kOMC  Analysis 
Results . 


* 

i  Risk  Ana  1 ys i s  for  Implementation 

•  The  findings  generated  from  tnis  research  were  usea  to 

I  identify  the  differences  between  the  existing  RED  HORSE 

squadron  environment  and  the  "ideal  implementation 

situation"  as  recommended  by  Alter  (2:155,158).  Under 

Alter's  ideal  implementation  environment 

-  the  system  is  to  be  produced  Dy  a  single 

implementer  for  a  single  user  who  anticipates 
1  using  the  system  for  a  very  definite  purpose  that 

|  can  be  specified  in  advance  with  great  precision. 

!  Including  the  person  who  will  maintain  it,  all 

parties  affecteu  oy  the  system  understand  and 
accept  in  advance  its  impact  on  them.  All 
!  parties  have  prior  experience  with  this  type  of 

system,  the  system  receives  adequate  support, 

I  and  its  technical  design  is  feasible  ana  cost- 

I  effective .  (2:157) 

Comparing  this  environment  with  that  in  a  typical  RED 
HORSE  squadron  indicates  eight  primary  differences  or  risk 
I  factors: 

1 .  Multiple  Implemente r s .  Interviews  with  HQ  AFESC, 
HQ  TAC,  and  RED  HORSE  squadron  personnel  indicated  some 
confusion  as  to  who  would  implement  automated  management 
systems  in  the  RED  HORSE  squadrons.  RED  HORSE  squadrons 
lack  the  expertise  required  to  implement  automated 
management  systems  and  must  rely  on  assistance  from  other 
organizations.  Problems  may  occur  when  attempting  to 
incorporate  the  interests  of  the  squadron  users,  the  MAJCOM 
and  HQ  AFESC. 
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2. 


Multiple  Users. 


Different  manage rs  witnin  the 


squadron  have  different  decis ion-making  information  needs 
ana  different  dec ision-mak ing  and  management  styles.  These 
individual  differences  must  be  considered  during  design  and 
implementation  to  facilitate  user  acceptance  and  ensure  the 
system  meets  the  individual  manager's  needs.  Also,  the 
system  will  require  data  to  be  provided  by  many  different 
sections.  Individuals  in  the  various  sections  may  provide 
data  in  a  "feeder  role"  (2:163),  but  may  not  directly 
benefit  from  it.  Thus,  they  may  lack  motivation  to  provide 
accurate  and  timely  inputs. 

3.  Lack  of  a  Clear  Predefined  Purpose .  Managers  in 
the  RED  HORSE  squadron  generally  have  a  good  idea  of  their 
own  section's  information  needs,  but  do  not  fully  understand 
or  appreciate  the  information  needs  of  other  sections  in  the 
squadron.  To  implement  a  well  integrated  system,  tnese 
needs  must  be  explored  and  the  system's  purpose, 
applications,  capabilities  and  limitations  must  be 
understood  by  all  users.  This  research  is  designed  to 
explore  user  needs  and  can  be  used  as  a  basis  for  defining 
the  purpose  of  the  system. 

4 .  User  Acceptance .  As  mentioned  in  Chapter  1 ,  the 
WANG  mini-computers  provided  to  the  820th  and  823rd  RED 
HORSE  squadrons  were  not  totally  accepted.  Managers  in 
these  squadrons  were  reluctant  to  support  the  cost  of 
installing,  operating,  and  maintaining  the  system  because 


tney  coaid  not  see  the  benefits  of  the  system  and  were  not 
provided  adequate  support  to  implement  tne  system.  Tne 
system  was  basically  a  forced  implementation,  witn  little  to 
no  user  initiation  or  participation. 

5 .  Lack  of  Prior  Knowledge  of  tne  System.  RED  HORSE 
squadrons  lack  prior  experience  with  the  more  complex 
automated  information  management  systems  like  BEAdS  or  WIMS. 
However,  they  are  developing  some  experience  with  "stand 
alone"  micro-computers  such  as  tne  Z-100  and  Z-24H.  Users 
will  most  likely  have  problems  understanding  the 
capabilities  of  a  new  system  and  the  use  of  its  applications 
software.  This  may  lead  to  disuse  (not  using  the  system)  or 
misuse  (using  the  applications  the  wrong  way). 


6.  Uncertainty  of 


The  initial  costs 


for  implementing  the  new  system  will  likely  be  too  hijn  for 
the  squadron  to  absorb  alone.  Inadequate  funding  may  delay 
tne  implementation  effort  or  cause  users  to  resent  the 
system  as  being  a  financial  millstone  around  tneir  necks. 
The  estimated  operating  and  maintenance  cost  for  the  new 
system  should  be  determined  during  tne  design  stage  so  tint 
the  squadron  can  budget  for  them  early. 

7 .  Uncer ta inty  of  Ope r a 1 1 ng  Support .  As  mentioned 
previously,  the  RED  HORSE  squadron  environment  r  > 
tnaracferued  by  a  constantly  fluctuating  *ork  tor,-’ 
people  are  moved  from  one  t>r  <]<•  !  <n  ■  ■X'T  i  s<>  t  -  n 
Because  RED  HORSE  personnel  ir  s  jo  )»•«**  r  ,•  i  >i  j  ,  i  . 
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TDY,  managers  are  concerned  tnat  trained  operators  will  not 
be  available  to  operate  the  system  (12). 


3 .  Uncertainty  of  Technical  Design  Feasibi lity . 
Because  of  their  lack  of  experience  with  automated 
information  management  systems,  and  ill-defineo  information 
needs,  the  new  system  may  not  be  designed  to  provide  the 
right  support  to  the  right  problems.  If  squadrons  are  to 
develop  the  system  on  their  own,  it  may  not  incorporate 
available  technology  or  achieve  the  level  of  integration 
required  to  provide  full  squadron  support. 

9 .  Uncertainty  of  Cost  Effectiveness.  Consider  a ole 
resources  may  be  invested  in  the  development  of  a  new 
system,  only  to  find  that  advances  in  technology  provide  a 
better  alternative.  Also,  it  is  difficult,  if  not 
impossible,  to  put  a  dollar  value  on  increased  effectiveness 
of  decision-making. 


J I .  CONCLUSIONS  AND  RLC JMMSNDA  I  IONS 

Tnis  chapter  presents  tne  conclusions  drawn  :r  >  r.  * 
analysis  presentee  in  the  previous  cnapter.  *.ne  cone.  I-- 
and  recommendations  from  tnis  researen  will  oe  discussed 
the  tnree  research  oojectives:  i 1 j  identity  areas  *uar  - 
MIS/DoS  systems  should  De  applied,  i2j  provide  recon.ne  .  1 
tions  for  the  development  of  specific  DSj  a pp 1  i  c at i . us  , 
[3]  provide  recommendations  for  tne  implementation  ana  L 
term  development  of  tnese  systems. 

Identi f y  MIS/ OSS  Appl icat ion  Areas 

Tne  analyses  iesenoed  in  Cnapter  a  were  usea  to 
satisfy  tne  first  research  oujective.  Ine  Data  Analysis 
Information  Needs  (Appendix  6 )  was  used  primarily  to 
identify  MIS  applications.  The  Key  Decision  Matrix 
(Appendix  C)  was  usea  to  identity  tnose  se:n-str  jct.t  .m 
unstructured  decisions  oest  supported  oy  DoS.  DSS 
applications  were  identified  tor  tne  decision-max  i:;, 
processes  descrioed  in  tne  normative  model.  Taole  4 
summarizes  tae  various  automated  management  applications 
recommended  for  R£D  riORSS  squadrons.  These  applications 
presented  for  eac.n  Key  manager  m  tne  RLD  HORSt  squadron 
Commande  r .  The  Commander's  pi  imary  decisions  am 
unstructured  mi  semi-st  r  act.  jr  m.  wh  i  l-»  tnese  dec  i  s  ions 
require  a  lar-je  decree  ot  intuition  on  th-n  part  or  tne 
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i.  \iso,  since  Key  managers 
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T'J'i ,  an  electronic  mail  utility 


-  •_  1  u  a  4  4  *  commander  s  to  .aa.e  messages,  tasiun^ ,  and 
.  ;  ].;u  les  tot  :us  start  penning  t.neir  return. 

le put  j  Qommanuer .  Most  ot  tne  Deputy  Comitanaer's 
decisions  are  unstructured  and  sem i- st r act u r ea .  The 
r  e commer. jo u  'CIS  applications  are  essentially  the  same  as  Cor 
tne  Oommander,  wit.n  more  detailed  report  information 
concerning  project  planning  and  design,  construction, 
personnel,  equipment,  training,  readiness,  and  squadron 
financial  status.  oSS  applications  include  a  module  tor 
projecting  Special  Operational  .Readiness  and  Traininq  Status 
(SORTS)  readiness  uata  cased  on  the  project  program 
scneduLe.  Also,  access  to  the  project  scheduling  module 
would  allow  him  to  assess  the  impact  of  schedule  changes  on 
training,  personnel,  and  equipment  availability. 
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Table  4. 


Summary  of  RED  HORSE  Automated  Management  System 
Appl icat ions . 

MIS  APPLICATIONS 

Project  status  reports  Material  status 

Personnel  status  reports  APR  and  Award  suspenses 

Vehicle  and  equipment  status  Leave  projections 

Financial  status  Labor  accounting  reports 

Training  rosters  Mobility  equipment 

inventory  management 

Mobility  readiness  status 
D3S  APPLICATIONS 

Automated  CPM  networks  Travel  cost  analysis 

Project  evaluations  Project  crew  selection 

Readiness  forecasting  Project  equip  selection 

Project  scheduling  Mobility  load  planning 

Financial  forecasting  Design  scheduling 

Training  scheduling  Design  and  construction 

cost  estimating 

Stock  level  estimating 
OTHER 

Electronic  mail 
Word  processing 

Director  of  Operations ■  The  DO  is  primarily  faced  with 
semi-structured  decisions.  Recommended  MIS  applications 
include  reports  to  provide  information  concerning  project 
planning  and  design  status,  construction  status, 
availability  of  branch  personnel,  equipment  status  and  long- 


range  availaoility ,  training  scnedules  for  brancn  personnel, 
branch  APR  and  award  suspenses,  mobility  team  status,  and 
branch  financial  status.  Several  DSS  applications  are 
recommended  for  this  manager.  First,  the  automated  CPM 
planning  module  used  by  the  Project  Engineer  to  determine 
project  construction  schedules  could  be  used  by  the  DO  to 
evaluate  the  affect  of  changes  in  the  construction  scneaule 
on  the  manpower  and  equipment  resources  used  by  the  project, 
and  to  compute  new  activity  start  and  completion  dates.  The 
equipment  planning  module,  used  by  DE  to  recommend  RED  HORSE 
equipment  for  deployment,  could  be  used  to  determine  the 
feasibility  of  deploying  additional  equipment  required 
during  a  project  deployment.  A  project  scheduling  module 
could  be  used  to  evaluate  alternative  project  schedules  ana 
determine  the  impact  on  equipment  and  personnel  availability 
as  well  as  scheduled  training  for  branch  personnel.  A  SORTS 
readiness  forecasting  module  could  be  used  to  give  the  00  a 
graphic  representation  of  the  squadron's  projected  readiness 
rating  over  time  based  on  a  given  troop  training  program 
schedule.  The  DO  could  also  benefit  from  a  financial 
forecasting  module  that  could  combine  expenditures  by  each 
section  and  display  graphic  representations  of  planned 
versus  actual  fund  expenditures  and  estimated  expenditures 
for  the  branch  based  on  historical  data.  Finally,  the  DO 
could  use  a  travel  cost  analysis  module  to  determine  the 
most  cost  effective  mode  of  travel  for  deploying 
individuals . 


Chief ,  Operations  Cente r .  Recommended  MIS  applications 


include  reports  to  provide  information  concerning  project 
planning  and  design  status,  construction  status, 
availability  of  branch  personnel,  equipment  status  and  long- 
range  availability,  detailed  training  and  personnel 
information  for  section  personnel,  and  project  and  worn 
order  material  cost  and  availability  information.  In 
addition,  an  automated  labor  accounting  module,  similar  to 
that  developed  for  WIMS,  is  recommended  to  automate  the 
preparation  of  weexly  work  schedules,  manhour  accounting, 
labor  reporting,  ana  the  preparation  of  the  In-house  worx 
Plan  (IWP).  Several  DSS  applications  are  recommended  for 
this  manager.  First,  the  automated  CPM  planning  module, 
used  by  the  Project  Engineer  to  determine  project 
construction  schedules,  could  be  used  by  the  D00  to  update 
project  status  as  progress  reports  are  received  from 
deployed  project  managers.  He  could  evaluate  the  affect  of 
changes  in  the  project's  construction  schedule  on  the 
manpower  and  equipment  resources  used  by  the  project  and  to 
compute  new  activity  start  and  completion  dates.  This 
information  could  be  provided  to  the  Project  Manager  ana 
used  to  update  the  troop  training  program  schedule.  The 
project  scheduling  module  could  oe  used  to  aevelop 
alternative  project  schedules  for  the  troop  training  program 
to  better  utilize  equipment  and  personnel  resources. 


Chief ,  Can to mne at  Flight.  The  Chief  of  Cantonment 
Flight  is  primarily  faced  with  structured  and  semi- 
structured  decisions.  Recommended  MIS  applications  include 
reports  to  provide  information  concerning  project  planning 
and  design  status,  construction  status,  availaoility  of 
section  personnel,  training  schedules  for  section  personnel, 
section  APR  and  award  suspenses,  OJT  status  for  section 
personnel,  mobility  team  assignments,  and  section  financial 
status.  Several  DSS  applications  are  recommended.  First, 
the  automated  CPM  planning  module  could  be  used  to  provide 
detailed  manpower  and  equipment  requirements  for  eacn  day  of 
the  proposed  project.  These  managers  could  use  this 
information  to  make  better  crew  assignments,  resource 
leveling,  and  for  recommending  changes  to  accelerate  goo 
progress.  This  manager  would  also  benefit  from  a  personnel 
scheduling  module  that  would  help  match  available  personnel 
with  project  requirements  after  checxing  for  conflicts  witn 
scheduled  leave,  training,  or  other  appointments. 

Chief ,  Airfields  Flight.  Recommended  MIS  applications 
are  essentially  the  same  as  for  the  Chief  of  Cantonment 
Flight,  but  should  include  detailed  reports  of  equipment  and 
vehicle  status  including  scheduled  maintenance  and  long-term 
availability,  and  project  ana  exercise  taskings  for  all 
equipment  assets.  DSS  applications  for  this  manager  are  the 


Pi rec to r  of  Logistics.  The  LG  is  primarily  faced  wich 
semi-structured  decisions.  Recommended  MIS  applications 
include  reports  to  provide  information  concerning  project 
status,  material  status,  availability  of  branch  personnel, 
equipment  status  and  long-range  availability,  training 
schedules  for  branch  personnel,  branch  APR  and  award 
suspenses,  mobility  team  status,  and  branch  financial 
status.  Several  DSS  applications  are  recommended  for  tnis 
manager.  First,  the  SORTS  readiness  forecasting  module 
could  be  used  to  give  the  LG  a  graphic  representation  of  the 
squadron's  projected  readiness  rating  over  time  oased  on  a 
given  troop  training  program  schedule.  The  LG  could  also 
benefit  from  a  financial  forecasting  module  that  coula 
combine  expenditures  by  each  section  and  display  graphic 
representations  of  planned  versus  actual  fund  expenditures 
and  estimated  expenditures  for  tne  branch  based  on 
historical  data. 

Chief ,  Log istic  Plans .  Tne  Chief  of  Logistic  PLans  is 
primarily  faced  with  structured  and  semi-structured 
decisions.  Recommended  MIS  applications  include  reports  to 
provide  information  concerning  project  status,  mobility  team 
assignments,  availability  of  squadron  personnel,  squadron 
training  status,  status  of  mobility  equipment  and 
increments,  training  schedules  for  section  personnel, 
section  APR  and  award  suspenses,  OJT  status  for  section 
personnel,  and  section  financial  status.  In  addition,  an 


MIS  system  for  monitoring  the  status  of  personnel  and 
equipment  preparation  during  exercises  or  contingency 
deployments  could  greatly  benefit  tliese  managers. 

Such  a  system  should  allow  all  sections  to  report 
manning  status  on  tneir  terminals  during  recalls.  The 
system  would  aggregate  the  information  by  shop  and  mooility 
team.  Requirea  processing  events  and  completion  times  coula 
be  displayed  on  terminals  in  each  section  and  at  the 
mobility  processing  cneck-points .  Each  section  ana  check¬ 
point  could  input  the  status  of  their  required  actions  and 
the  system  could  compute  new  estimated  completion  times  and 
flag  problem  areas. 

Several  DSS  applications  are  recommended  for  this 
manager.  First,  an  automated  load  planning  module  similar 
to  the  existing  micro-computer  based  Contingency  Operations/ 
Mobility  Planning  and  Execution  System  (COMPES)  should  be 
provided  to  allow  load  plans  to  be  quickly  developed  for 
various  aircraft  and  cargo  requirements.  The  SORTS 
readiness  forecasting  module  could  be  used  to  aggregate 
personnel,  equipment,  and  training  information  into  the 
monthly  SORTS  readiness  report  and  to  provide  a  graphic 
representation  of  the  squadron's  projected  readiness  rating 
over  time  based  on  a  given  troop  training  program  schedule. 
It  could  also  help  managers  evaluate  the  effect  that  changes 
in  mobility  tea.n  personnel  assignments  would  have  on  the 
SORTS  rating. 


Chief ,  Supply  Section .  The  Chief  of  Supply  is 
primarily  faced  with  structured  and  semi-structured 
decisions.  Recommended  MIS  applications  include  reports  to 
provide  information  concerning  project  status;  availaoility 
of  section  personnel;  status  of  materials,  equipment,  and 
weapons  maintained  as  mobility  increments;  training 
schedules  for  section  personnel;  section  APR  and  award 
suspenses;  OJT  status  for  section  personnel;  and  section 
financial  status.  In  addition,  the  MIS  system  should  be 
capable  of  direct  interface  with  the  host  base  BCE  and  Base 
Supply  automated  systems  for  ordering  materials,  making 
inquiries,  monitoring  status  of  materials  and  equipment  on 
order,  and  obtaining  cost  and  fund  status  reports. 

Other  MIS  applications  include  automated  inventories  of 
mooility  equipment  ana  individual  mobility  bags  to  help  cut 
down  the  time  required  to  inventory,  order,  and  fill 
personnel  clothing  shortages.  A  transaction-based  MIS 
system  for  material  issues  and  returns  could  also  help  this 
manager  better  control  materials,  while  providing  real-time 
residual  material  stock  levels  to  planners  developing  Bill 
of  Material  (BOM)  for  RED  HORSE  projects.  One  potential  DSo 
application  is  a  module  for  estimating  material  requirements 
based  on  historical  data. 

Chief,  Vehicle  Maintenance  Section .  The  Chief  of 
Vehicle  Maintenance  is  primarily  faced  with  structured  and 
semi-structured  decisions.  Recommended  MIS  applications 


include  reports  to  provide  information  concerning  project 
schedules,  project  status;  equipment  and  vehicles  scheduled 
for  deployment;  status  of  equipment  maintained  as  mobility 
increments;  availability  of  section  personnel;  training 
schedules  for  section  personnel;  section  APR  and  award 
suspenses;  OJT  status  for  section  personnel;  and  section 
financial  status.  The  MIS  system  should  be  capable  of 
direct  interface  with  COPARS  for  ordering  parts;  making 
inquiries;  monitoring  status  of  parts  and  equipment  on 
order;  and  obtaining  inventory,  cost,  and  fund  status 
reports.  In  addition,  the  system  should  provide  a  direct 
interface  with  the  host  base  VIMS  system  for  transferring 
vehicle  maintenance  information.  This  would  prevent  users 
from  having  to  duplicate  data  entry  into  both  systems. 
Potential  D3S  application  areas  include  a  module  for 
estimating  WRSK  and  COPARS  parts  and  material  stock  levels 
based  on  historical  consumption  data  and  a  module  to  assist 
managers  in  developing  work  scnedules  based  on  vehicles 
scheduled  for  deployment,  scheduled  maintenance,  and 
personnel  availaoility . 

Pi  recto  r  of  Engineering.  The  DE  is  primarily  faced 
with  semi-structured  decisions.  Recommended  MIS 
applications  include  reports  to  provide  information 
concerning  project  planning  and  design  status,  construction 
status,  availability  of  branch  personnel,  equipment  status 
and  long-range  availability,  training  schedules  for  branch 


personnel,  branch  APR  ana  awara  suspenses,  mooility  team 
status,  and  branch  financial  status.  In  addition,  the 
automated  system  should  provide  automated  engineering  laoor 
accounting  to  allow  planning  and  design  costs  to  be  computea 
ana  charged  against  each  project.  Several  DSS  applications 
are  recommended  for  this  manager. 

First,  an  automated  design  scheduling  moaule  could  oe 
used  to  develop  the  RED  HORSE  in-house  design  schedule  based 
on  project  design  requirements  and  the  availability  of 
engineers.  A  design  manhour  estimating  module  could  be  used 
to  estimate  the  number  of  design  nours  required  for  each 
project  by  skill  based  on  historical  labor  accounting  data. 
The  automated  CPM  planning  module  used  by  the  Project 
Engineer  to  determine  project  construction  schedules  could 
oe  used  by  the  DE  to  review  construction  schedules  and 
recommend  changes  to  better  utilize  manpower  and  equipment 
resources.  A  project  scheduling  module  could  be  used  to 
evaluate  the  effect  design  schedules  have  on  the  troop 
training  program  schedule.  As  the  RH-1  mobility  team 
Commander,  the  DE  could  use  the  SORTS  readiness  forecasting 
module  to  produce  a  graphic  representation  of  the  squadron’s 
projected  readiness  rating  over  time,  based  on  a  given  troop 
training  program  schedule.  The  DE  could  also  benefit  from  a 
financial  forecasting  module  that  could  combine  expenditures 
by  each  section  ana  display  graphic  representations  of 
planned  versus  actual  fund  expenditures  and  estimated 
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expenditures  for  tne  crunch  based  on  historical  data. 

Finally,  the  DE  could  use  a  travel  cost  analysis  module  to 
determine  the  most  cost  effective  mode  of  travel  for 
deploying  individuals. 

Chief ,  Engineering  Design  Section.  The  MIS/DSS 
applications  for  the  Chief  of  Design  are  essentially  tne 
same  as  for  the  DE. 

Project  Eng ineer .  Recommended  MIS  applications  include 
reports  to  provide  information  concerning  project  planning 
and  design  status,  construction  status,  availability  of 
squadron  personnel,  equipment  status  and  long-range 
availability.  Several  DSS  applications  are  recommenaea  for 
use  by  the  Project  Engineer.  First,  A  construction  cost 
estimating  module  could  be  used  to  estimate  the  manpower  and 
equipment  required  for  a  project  as  well  as  the  estimated 
costs.  An  automated  CPM  planning  module  coula  be  used  oy 
the  Project  Engineer  to  determine  project  construction 
schedules,  manpower  and  equipment  resource  requirements  by 
day,  and  activity  start  and  completion  dates.  The  equipment 
planning  module  could  be  used  by  PE  to  recommend  RED  HORSE 
equipment  for  deployment. 

Headquarters  Squad ron  Section  Commander .  The  Squadron 
Section  Commander's  primary  decisions  are  unstructured  and 
semi-structured.  while  these  decisions  require  a  large 
degree  of  intuition  on  the  part  of  this  manager,  they  can 
best  be  supported  by  MIS  applications  that  provide  detailed 


and  accurate  personnel  information  on  all  individuals 


assigned  to  the  squadron.  The  system  should  also  provide 
reports  on  personnel  aval Laoi 1 i ty ,  squadron  APR  and  award 
suspenses,  status  of  personnel  actions,  and  financial  status 
information  for  nis  section. 

Squadron  First  Sergeant.  Tne  MI3/USS  applications  for 
the  First  Sergeant  are  essentially  the  same  as  for  tne 
Headquarters  Squadron  Section  Commander. 

Chief ,  Unit  Administration.  The  Chief  of 
Administration's  primary  decisions  are  well  structured. 

Most  of  this  manager's  decision-making  needs  can  best  be 
supported  by  MIS  applications  that  provide  aetaiLed 
personnel  information;  and  status  on  correspondence,  APRs, 
and  awards. 

Funds  Manager .  The  Funds  Manager  is  primarily  faced 
with  semi-structured  decisions.  Recommended  MIS 
applications  include  reports  to  provide  information 
concerning  project  planning  and  design  status,  construction 
status,  sguadron  fund  expenditures  by  section,  labor  hours 
against  projects,  material  costs  for  projects,  availability 
of  section  personnel,  training  schedules  for  section 
personnel,  section  APR  and  award  suspenses.  In  addition, 
the  automated  system  should  provide  an  interface  with  the 
host  base  finance  office  for  real-time  squadron  financial 
status.  D53  applications  include  spreadsheets  for 
summarizing  and  graphing  financial  data  and  a  financial 
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estimating  module  to  estimate  funding  requirements  to 
support  the  current  troop  training  project  schedule. 


Chief ,  Training  Branch.  The  Cnief  of  Training  is 
primarily  faced  with  semi-structured  decisions.  Recommended 
MIS  applications  include  reports  to  provide  information  sucn 
as  squadron  training  rosters,  personnel  availability, 
project  scnedules,  mobility  team  assignments,  squadron  OJC 
status,  and  section  APR  and  award  suspenses.  Primary  DS3 
applications  involve  a  training  scheduling  module  to  ouild 
master  training  scheaules  for  all  squadron  personnel  based 
on  training  requirements  and  projected  personnel 
availability. 

Recommendations  for  Development  of  Specific  DSS  Applications 
A  large  portion  of  the  decision-making  information  used 
by  managers  in  this  squadron  is  fragmented  ana  aifficult  to 
obtain,  as  individual  managers  capture  only  the  data  they 
need.  When  provided  to  others,  information  usually  lacks 
both  the  format  and  level  of  detail  required  for  effective 
use.  Voluminous  information — particularly  project  status; 
personnel  and  equipment  status  and  availability;  and 
training  requirements--is  captured  by  many  sections  in  a 
common  effort  to  accomplish  projects  and  maintain  mobility 
readiness.  The  large  degree  to  which  information  should  oe 
shared  suggests  a  strong  need  for  an  automated  management 
information  network  system. 


Altnough  it  was  not  an  original  research  objective,  tne 
results  of  this  research  support  and  validate  many  of  the 
findings  of  the  1 9d5  RED  HORSE  Information  Management  System 
(RHIMS)  study.  While  the  research  results  supported  the 
study's  recommended  applications  and  general  system 
requirements,  it  provided  little  support  to  the  need  for  an 
automated  interface  between  RED  HORSE  squadrons. 

A  mini-computer  based  network  system,  as  suggested  by 
the  original  RHIMS  study,  should  be  used  to  support  the 
applications  recommended  in  the  research.  This 
recommendation  is  based  on  the  high  volume  of  data  shared 
between  the  various  squadron  sections,  the  need  for  rapid 
communication  and  data  transfer  between  squadron  managers, 
and  the  large  data  storage  capability  required  to  support 
the  suggested  applications. 

The  results  of  the  ROMC  analysis  (Appendix  D)  were 
summarized  to  determine  the  general  system  capabilities 
required  to  support  the  recommended  applications: 

1.  A  user-friendly  menu-driven  system. 

2.  The  ability  to  extract  data  rapidly  from  a  wiae 
variety  of  databases. 

3.  The  ability  to  support  a  complex  system  of  user 
privileges  and  file  protection  to  allow  information 
to  be  input  by  one  individual,  used  by  another,  and 
denied  to  others.  This  would  provide  protection 
and  accountability  for  data  supplied  to  the  system 
while  protecting  Privacy  Act  information,  such  as 
personal  data,  from  unauthorized  use. 

4.  The  capability  to  easily  format  reports  tailored  to 
the  individual  manager's  decision-making  needs  by 
extracting  data  from  master  databases  without 
changing  the  original  data. 
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5. 


Tne  capability  to  support  new  applications  or 
change  existing  applications  as  decision  needs 
cnange.  This  .nay  oe  facilitated  tnrough  easy-to- 
use  programming  languages. 

6.  The  capability  to  interface  wi tn  host  base 
automated  management  systems  through  modems  or 
dedicated  lines. 

7.  The  capability  to  provide  graphic  representations 
of  data. 

8.  The  capaoility  to  store  historical  data  such  as 
project  cost,  vehicle  maintenance  histories,  ana 
labor  utilization,  on  high  volume  aata  storage 
devices  such  as  disk  drives  and  magnetic  tape. 

9.  The  capability  to  support  word  processing  and 
electronic  mail  functions. 

The  findings  generated  by  this  research  inaicate  a 
complex  system  of  information  flows  witnin  the  RED  HORSE 
squadron.  A  staged  development  approacn  is  recommended  for 
developing  these  MIS/OSS  applications.  The  results  of  tnis 
research  should  be  reviewed  by  both  tne  users  ana  system 
designers  to  estaolish  a  concept  of  operation  within  which 
specific  prototype  applications  would  be  developed.  These 
applications  should  focus  on  decision  areas  that  offer  a 
high  payoff  tnrough  automated  support.  This  will  provide 
specific  applications  to  generate  user  interest  and  provide 
a  basis  for  developing  other  applications. 

While  it  was  not  an  objective  of  this  research  to  make 
specific  recommendations  as  to  the  type  of  automated 
equipment  that  should  be  obtained  for  RED  HORSE  squadrons, 
the  findings  indicate  sufficient  applications  to  warrant  the 
use  of  a  mi n i -computer  network  system. 
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The  existing  WANG  mini-computers  at  both  squaarons 
should  be  used  to  support  the  MIS/OSS  applications  described 
in  this  report.  The  wANG  mini-computer  is  recommended  for 
several  reasons.  First,  the  equipment  is  on  hand  in  Doth 
RED  HORSE  squadrons.  However,  since  tne  equipment  was 
obtained  as  excess  equipment  from  other  bases,  it  must  be 
carefully  inventoried,  and  missing  or  damaged  parts  must  oe 
replaced.  Second,  the  WANG  equipment  is  being  purchased  as 
the  standard  system  for  Engineering  and  Services 
organizations  worldwide.  Because  of  this,  many  applications 
developed  by  Base  Civil  Engineering  units  could  be  modified 
or  used  directly  by  RED  HORSE  squadrons.  Furthermore,  RED 
HORSE  squadrons  could  benefit  from  the  interface 
capabilities,  with  other  base  computers,  being  developed  for 
the  WANG  based  WIMS  system  (26).  Finally,  the 
implementation  of  tne  WANG  equipment  in  other  Engineering 
and  Services  organizations  should  ease  the  implementation 
effort  for  RED  HORSE  squadrons,  since  personnel  transferred 
from  BCE  squadrons  to  RED  HORSE  squadrons  would  benefit  from 
prior  experience  with  the  WANG  equipment.  Also,  technical 
assistance  could  be  obtained  from  the  MAJCOMS  and  HQ  AFESC, 
who  have  extensive  experience  with  the  WANG  equipment. 


System  Implementation  and  Long-term  Development 

This  section  will  discuss  a  general  strategy  for 
successful  implementation  of  automated  management  systems 
for  RED  HORSE  squadrons.  Although  the  specific 


implementation  tasks  performed  will  depend  on  the  type  of 
system  chosen,  the  guidelines  presented  here  should  apply  to 
any  implementation  effort.  The  r ecommendea  strategy  was 
developed  by  combining  strategies  recommended  by  Keen  and 
Morton  (2tt),  Alter  (2),  and  Multinovich  and  Vlanovicn  (32) 
into  a  general  strategy  directed  toward  the  reduction  of  tne 
implementation  risk  factors  developed  in  Chapter  b.  The 
recommended  implementation  strategy  is  outlined  below: 

1 .  Determine  User  Needs .  In  this  phase,  the  «ED  HGksE 
organizational  environment  is  examined  to  determine  problems 
requiring  automated  support  (32:10)  and  to  determine  the 
degree  to  which  users  feel  a  need  for  an  automated  system. 
During  this  phase,  discussions  with  users  help  them  better 
conceptualize  their  decision-making  information  needs.  This 
aids  in  developing  a  clear  pre-defined  purpose,  and  reduces 
the  risk  of  technical  design  problems.  User  initiation  is 
established  early  as  individuals  are  given  the  opportunity 
to  voice  their  ideas  and  make  recommendations  for  automated 
support.  User  involvement  snould  be  maintained  through  the 
implementation  process.  This  serves  to  improve  user 
acceptance  by  securing  user  initiation  ano  involvement. 

2 .  Develop  an  Implementation  Plan.  In  this  phase,  a 
concept  of  operation  is  developed  that  defines  the  purpose 
of  the  system,  the  application  areas,  and  general 
capabilities  of  the  system.  This  provides  the  written 


definition  of  an  immediate  and  visible  problem  to  work  on,  a 


critical  factor  noted  by  Keen  (28:19b).  This  plan  will  nelp 
users  understand  the  system's  impact  on  them  and  facilitate 
their  acceptance.  Active  support  ana  participation  by 
automation  experts  from  HQ  TAG  and  HQ  AFESC  is  required  to 
guide  the  squadrons  in  the  development  of  this  plan.  This 
plan  should  address  all  risk  factors  affecting  successful 
implementation/  and  tnerefore  serves  to  reduce  all  risk 
factors . 

3.  Acquire  Required  System  Support.  This  phase 
involves  "selling  the  system  to  users  and  top  management" 

(2;  2b).  Top  management  support,  both  at  the  squadron  level 
and  MAJCOM,  is  required  to  secure  support  for  resources 
required  to  effectively  design,  install,  ana  implement  the 
system.  Top  management  support  provides  a  clear  signal  that 
management  supports  the  effort  and  heaps  secure  the 
cooperation  and  support  of  users.  MAJCOM  support  helps 
provide  the  technical  assistance,  equipment  and  funaing 
required  to  develop,  install,  and  maintain  the  system. 

4 .  Form  an  Implementation  Team .  During  this  phase  a 
team  is  formed  to  monitor  the  overall  development  and 
implementation  effort  and  to  improve  communication  between 
the  system  designers  and  the  users.  To  better  integrate  the 
system  applications  between  the  various  squadron  sections, 
the  ♦•earn  should  include  one  representative  from  each  branch 
and  special  staff  function.  It  is  also  recommended  tnat  the 
squadron  Deputy  Commander  serve  as  chairman  of  tnis  team  to 


resolve  possiole  conflict  between  branches  during 
implementation.  The  implementation  team  should  attempt  to 
maintain  user  involvement  and  Keep  them  informed  of  the 
implementation  progress,  through  periodic  briefings  at  staff 
meetings  and  Commander's  Calls.  This  strategy  helps  reduce 
the  problems  associated  with  multiple  implementers  and 
multiple  users,  by  providing  a  focal  point  for  incorporating 
the  interests  of  all  users  into  the  system  development 
effort. 

5 .  Use  an  Evolutionary  Approach.  The  system  should  be 
designed  and  implemented  using  an  iterative  process,  with 
frequent  feedback  from  users  to  ensure  tne  system  satisfies 
their  needs.  This  will  prevent  the  expenditure  of  much  time 
and  resources  developing  a  system  that  doesn't  worn.  when 
introducing  the  system  into  the  squadron,  implementers 
should  be  careful  not  to  overwhelm  the  users  witn  tasks  and 
responsibilities,  or  cause  such  a  disruption  to  their 
activities  as  to  create  resentment  toward  the  system.  If 
the  system  is  complex,  with  many  capabilities  and 
applications,  it  should  be  introduced  in  stages. 

The  simplest  applications,  such  as  word  processing  and 
electronic  mail,  should  be  introduced  first.  This  will 
provide  users  with  immediate  and  useful  applications  and 
help  generate  their  interest  and  enthusiasm.  Next, 
databases  and  small  models  should  be  introduced  to  provide 
information  reports  and  other  MIS  applications  to  improve 


the  flow  of  decision-making  information  through  tne 
squadron.  Since  most  information  is  maintained  in  a  manual 
information  system,  much  time  will  oe  required  to  input  aata 
into  the  system.  The  implementation  team  and  system 
tecnnical  support  personnel  should  wors  closely  witn 
individual  users  during  this  phase  to  ensure  they  understand 
how  the  information  will  oe  used,  and  to  ensure  it  is 
accurate  and  in  the  correct  format.  Finally,  as  users  gain 
more  proficiency  in  the  use  of  the  system,  and  the  databases 
are  established,  prototype  DSS  modules  should  be  introduced. 

System  designers  should  work  with  DSS  users  to  design 
these  modules  while  the  MIS  applications  are  being 
introduced.  These  prototype  DSS  modules  should  provide 
decision  support  in  "high  payoff  areas",  such  as  project, 
design,  and  training  scheduling;  and  personnel  ana  equipment 
selection.  This  will  allow  users  to  gain  immediate  benefits 
while  serving  as  a  starting  point  for  the  development  of 
other  applications. 

6 .  Institutionalize  tne  System.  After  the  system  is 
introduced  into  the  squadron,  specific  actions  are  required 
to  ensure  the  system  meets  users'  needs.  During  this  phase, 
training  must  be  provided  to  all  users  and  system 
maintainers. 

Training  should  be  accomplished  in  a  formal  classroom 
setting,  using  realistic  example  problems  that  the  user  can 
relate  to.  Training  manuals  should  be  written  from  the 


user's  point  of  view--not  tne  pr  og  r  amme  r  ’  s--and  snould 
explain  how  to  use  the  system  instead  of  how  tne  system  was 
constructed  (37:3o).  Training  should  emphasize  what  the 
system  can  do  for  the  user,  instead  of  emphasizing  rigid 
requirements  for  the  user  to  support  the  system.  Finally, 
care  must  be  taken  to  avoid  overwhelming  the  trainees  with 
too  much  documentat ion  at  the  beginning  of  the  training,  or 
they  will  become  so  frustrated  that  tneir  learning  effort 
will  oe  blocked  (37:3:*).  Training  courses  should  be 
carefully  sequenced  to  meet  user  needs.  Documentation 
should  be  written  at  a  level  "below  the  perceived 
comprehension  level  of  the  intended  reader"  (37:38). 

Management  should  also  adopt  a  policy  tnat  encourages 
voluntary  use  of  the  system  by  allowing  users  to  be  creative 
in  the  development  of  new  applications  or  the  retinement  of 
existing  applications,  tailored  to  meet  their  individual 
management  style.  In  other  cases  management  must  insist  on 
mandatory  use.  This  is  required  when  "the  system  is  a 
medium  for  integration  and  coordination  in  planning" 

(2:169).  Mandatory  use  will  most  likely  be  required  in 
maintaining  current  ana  accurate  personnel,  project, 
equipment,  and  training  data.  In  these  cases,  the  user's 
responsibility  for  data  used  by  the  system  must  be  clearly 
defined . 
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Recommendations  for  Further  Stud 


As  mentioned  in  the  scope  and  limitations  of  Chapter  1 , 
this  research  did  not  address  the  automation  needs  of  a  RED 
RORSE  squadron  deployed  under  field  conditions.  Pernaps 
critical  information  could  be  down  loaded  from  the  squadron 
mini-computer  to  small  micro-computers  that  could  be  easily 
deployed  with  the  deploying  mobility  team.  Future  research 
should  address  these  needs.  The  methodology  used  in  tnis 
research  effort  could  be  used  to  accomplish  that  objective. 

Future  researchers  should  also  consider  the  effect  of 
technology  on  our  automated  management  systems.  Continued 
research  is  required  to  assess  technolog ical  advances  in 
automated  systems  and  the  potential  application  of  that 
technology  to  Air  Force  Engineering  and  Services.  Continued 
effort  is  required  to  develop  specific  programs  to  support 
our  managers  and  their  aecision  support  applications. 

Finally,  future  researchers  should  address  the  need  for 
evaluating  the  performance  of  our  automation  development 
efforts  to  provide  feedback  for  monitoring  the 
implementation  process,  for  better  defining  future 
automation  requirements,  and  to  provide  some  "lessons 
learned"  tnat  could  be  applied  to  future  development 
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Appendix  D:  ROMC  Analysis  Results 

The  required  DS3  capaoilities  for  various  decisions 
were  determined  by  first  analyzing  each  decision  in  terms  of 
Simon's  three  stages  of  decision  making,  then  identifying 
the  ROMC  components  related  to  eacn  stage. 

DECISION:  Considering  the  affect  on  mobility  team  readiness, 
should  I  approve  this  project  schedule?  ( CC ,  CO, 
DO) 

INTELLIGENCE 

-  Gatner  data  on  projects  scheduled  for  a  particular 
time  period 

-  For  eacn  of  the  above  projects,  identify  the 
specific  personnel  and  equipment  assets  scheduled  to 
deploy  on  the  project  for  each  day 

-  For  each  individual  and  each  equipment  item  identify 
the  mobility  team  assigned 

DESIGN 

-  Summarize  data  elements 

-  Plot  the  total  percentage  of  people  available 
against  time  for  each  project  with  separate  graph 
line  representing  the  total 

-  Plot  the  total  percentage  of  equipment  available 
against  time  for  each  project  with  separate  graph 
line  representing  the  total 

CHOICE 

-  Select  the  mobility  team  whose  mobility  status  you 
want  to  graph 

-  Select  for  removal  a  project  that  has  the  greatest 
impact  on  mobility  team  readiness 

-  Chose  other  alternative  project  schedules  to  plot 


Summarizing  the  above  in  terms  of  tne  ROMC  components. 


we  identify  the  following  the  following  required  DS3 
capabilities : 

REPRESENTATIONS 

-  Lists  of  projects 

-  Lists  of  personnel  and  equipment  for  each  project 

-  Graphs  of  assets  available  versus  time 
OPERATIONS 

-  Ouery  the  data  base 

-  Extract  and  combine  elements  from  multiple  databases 

-  Summarize  statistics  for  the  data 

-  Plot  graphs 

-  Print  tables  or  graphs 
MEMORY  AIDS 

-  Extracted  data  on  projects 

-  Work  space  for  saving  information  displayed 

-  Databases 
CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  and  error  messages 
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DECISION:  Can  we  design  this  project  In-nouse?  Who  should 
I  assign  as  Project  Engineer?  How  should  I 
assign  engineers  to  this  design  effort?  (DE, 

DEE ) 

INTELLIGENCE 

-  Review  current  design  schedule 

-  Review  Troop  Training  Project  schedule  for 
individual  project  start  date,  completion  date,  ana 
priority 

-  Review  availability  of  each  engineer  using  leave  ana 
TDY  schedules 

-  Define  major  activities  and  manhours  requirea  for 
each  project 

-  For  each  engineer,  determine  his  skill  (Civil, 
Electrical,  etc.),  the  percent  of  time  available  for 
design,  and  his  relative  efficiency 

DESIGN 

-  Starting  with  the  highest  priority  project,  assign 
individuals  based  on  their  skill,  availability  ,  and 
efficiency 

-  Compute  activity  start  and  completion  dates  based  on 
design  hours  required  for  each  activity,  tne  percent 
of  the  time  the  individual  is  available  for  design, 
and  his  efficiency 

-  Adgust  availability  information  for  each  individual 
as  he  is  scneduled 

-  Repeat  for  next  highest  priority  project,  then  the 
next,  until  all  projects  are  scheduled 

-  Display  recommended  design  schedule 

CHOICE 

-  Manually  choose  individual  engineers  to  be  assigned 
to  specific  projects  or  activities 

-  Select  new  activity  start  and  completion  dates 

-  Update  current  design  schedule,  delete  tnis 
analysis,  or  perform  new  analysis 


133 


.  a<m  k  .»  m Mfci ik.  ii.  ti_m  ».i  ».i  *~i  «.i  1.1  t.i  «-t  t  j  t-i  i.i  ■  j. 


:3 


>1 


iSWW 


Summarizing  tne  above  in  terms  of  tne  ROMC  components, 


we  identify  the  following  the  following  required  DS3 


capabilities : 


REPRESENTATIONS 


-  Lists  of  projects  and  their  status  information 


-  Lists  of  personnel,  their  skill,  and  availability 


Gantt  chart  for  displaying  design  schedules 


-  Screen  forms  for  data  entry 


operation;; 


-  Query  multiple  aa cabases 


-  Extract  and  combine  elements  from  multiple  databases 


-  Select  individual  for  task  based  on  predetermined 
decision  rules 


-  Update  engineer  availability  to  reflect  each  task 
assigned 


Compute  start  and  completion  dates  for  each  task 


-  Plot  Gantt  Charts 


-  Print  tables  or  charts 


MEMORY  AIDS 


-  Extracted  data  on  projects,  design  requirements,  and 
engineer  availability 


-  Work  space  for  saving  information  displayed 


-  Databases  for  maintaining  design  schedule 


CONTROL  MECHANISMS 


-  Menus  and  function  Keys 


-  Help  Screens  and  error  messages 
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DECISION:  How  should  we  distribute  squaaron  obligation 
authority?  What  are  our  quarterly  fund 
requirements?  ( FM ) 

INTELLIGENCE 

-  Review  budget  request  from  each  brancn 

-  Review  project  schedule 

-  Review  funds  required  to  support  each  project 
DESIGN 

-  Divide  projects  according  to  the  fiscal  quarter  in 
which  they  will  be  accomplished 

-  Total  the  funds  required  for  all  projects  in  each 
quarter  by  EEIC 

-  Total  the  funds  required  for  all  branches  in  eacn 
quarter  by  EEIC 

-  Add  funds  required  to  support  training  projects  to 
funds  required  by  each  branch 

-  Graph  funds  required  for  each  quarter  by  EEIC 
CHOICE 

-  Select  line  item  from  branch  budget  request  or 
project  fund  requirement  for  change 

-  Select  another  time  perioa  for  analysis 

-  Select  information  to  be  displayed,  printed,  or 
graphed 

Summarizing  the  above  in  terms  of  the  ROMC  component 
we  identify  the  following  the  following  required  DS3 
capabilities : 

REPRESENTATIONS 

-  Display  Branch  Budget  request  documents 

-  On-screen  Data  entry  forms 

-  Lists  of  projects 


-  Lists  of  funds  required  for  each  project 

-  Graphs  of  planned  versus  actual  expenditures 
OPERATIONS 

-  Query  multiple  dacaoases 

-  Sort  projects  by  data 

-  Summarize  cost  data  for  projects  by  time  period 

-  Combine  cost  data  from  multiple  databases 

-  Plot  graphs 

-  Print  tables  or  graphs 
MEMORY  AIDS 

-  Extracted  project  cost  data 

-  workspace  for  saving  information  displayed 

-  source  databases  for  project  scneduling  and  cost 
data 

-  source  databases  for  Branch  and  project  fund 
expenditures 

CONTROL  MECHANISMS 

-  Mark  and  bound  key  to  highlite  displayed  data 

-  Menus  and  function  keys 

-  Help  screens  and  error  messages 

-  Flashing  data  fields  to  indicate  incomplete  data  or 
data  that  needs  updating 
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ION:  What  stock  levels  should  we  estaolisn  for  our  war 
Readiness  Spares  Kits  (wRSK)?  { LGT ) 

INTELLIGENCE 

-  Examine  historical  data  from  maintenance  worx  order 
f  iles 

-  Examine  current  WRSK  inventory  aata 

-  Examine  type  and  number  of  vehicles  and  heavy 
equipment  items  assigned  to  each  mobility  team 

-  Estimate  the  mileage  or  hours  of  operation  for  each 
type  of  equipment  on  each  mobility  team 

DESIGN 

-  Determine  the  parts  used  and  vehicle  type, 
registration  number,  and  mileage  or  operation  hours 
for  each  vehicle  or  heavy  equipment  item 

-  Total  the  number  of  each  type  part  required  for  each 
vehicle  and  its  total  mileage  or  operation  hours 

-  Compute  failure  rate  for  each  part  based  on  mileage 
or  operation  hours 

-  Compute  expected  quantity  of  parts  required  by  part 
number  and  vehicle  or  equipment  type  for  each 
mobility  team 

-  Display  results 

CHOICE 

-  Select  time  period  for  analysis 

-  Change  estimates  of  mileage  or  operation  hours  for 
each  vehicle 
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Summarizing  the  above  in  terms  of  the  ROMC  components, 
we  identify  the  following  the  following  required  OSS 
capabilities : 


REPRESENTATIONS 

-  Lists  of  part  numbers,  stock  numbers,  quantity  on 
hand,  and  quantity  required 

-  On  screen  data  entry  forms 

-  Parameters  to  be  selected  in  performing  an  analysis 

OPERATIONS 

-  Extract  data  from  multiple  databases 

-  Sort  extracted  data 

-  Compute  part  consumption  rates  cased  on  historical 
consumption  data  and  mileage  or  operating  hours 

-  Save  resulting  information 

-  Compute  required  stock  levels  for  time  period 
selected 

MEMORY  AIDS 

-  Archived  databases  on  tape  or  other  mass  storage 
devices 


-  Result  databases 

-  Workspace  for  storing  displayed  information 


CONTROL  MECHANISMS 

-  Mark  and  bound  key  to  highlite  displayed  data 

-  Menus  and  function  keys 

-  Help  screens  and  error  messages 

-  Flashing  data  fields  to  indicate  incomplete  data 
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DECISION:  Who  should  I  assign  to  this  project  crew? 
OOP) 


DOS, 


INTELLIGENCE 

-  Review  project  requirements 

-  Review  personnel  availability 

-  Review  training  schedule 

-  Review  individual  personnel  TDY  history 

DESIGN 

-  List  personnel  available  durinq  project  timeframe 

-  Search  training  database  for  each  individual  listed 
to  determine  and  list  all  training  conflicts 

-  Search  personnel  database  for  each  individual  to 
determine  and  list  all  required  personnel  actions 
and  appointments 

-  Display  individuals  selected,  tneir  last  TDY, 
duration,  and  total  number  of  days  TDY  in  last  12 
months 

-  Update  personnel  database  to  reflect  availability 
status  for  individuals  selected 

CHOICE 

-  Select  time  period  for  analysis 

-  Select  search  parameters  (AFSC,  name,  shop  assigned) 

-  Select  individual  for  assignment  to  project 
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summarizing  the  above  in  terms  of  the  ROMC  components 
we  identify  the  following  the  following  required  DS3 
capaoilities : 

REPRESENTATIONS 

-  Lists  of  projects,  personnel  required,  personnel 
available,  training  and  appointment  conflicts 

-  Search  parameters  for  selecting  type  of  analysis 
OPERATIONS 

-  Query  the  multiple  data oases 

-  Extract  data  subsets  from  multiple  databases 

-  Search  for  matching  parameters 

-  Display  lists 

-  Print  lists 

-  Update  databases 
MEMORY  AIDS 

-  Extracted  data  on  projects 

-  Extracted  data  on  personnel 

-  Work  space  for  saving  information  displayed 

-  Databases 
CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  ana  error  messages 

-  Functions  to  "Highlite"  or  mark  selected  data 


DECISION:  Considering  that  possible  changes  in  a  project 
start  date  may  cause  deployed  personnel  to  miss 
scheduled  training,  snould  I  approve  this  project 
crew  list?  (CC,  CD,  DO) 


INTELLIGENCE 


-  Select  a  project  from  the  project  schedule 


-  Gather  data  on  individuals  scheduled  for  this 
project 


-  User  specifies  a  time  period  for  the  sensitivity 
analysis  (.  number  of  days  for  early  start,  +n,  or 
number  of  days  for  late  start,  -n  ) 


DESIGN 


-  Adjust  each  persons  scheduled  deployment  period  by 
the  number  of  days  specified  for  the  analysis 


-  Search  master  training  database  for  scheduled 
training  required  by  each  individual  for  the 
adjusted  deployment  period 


-  Display  resulting  data  by  individuals  name,  type 
training,  ana  date  requireo 


CHOICE 


-  Select  individual  for  replacement 


-  Insert  name  of  alternate  individual  for  assignment 
consideration  and  repeat  the  analysis 


-  Select  another  time  period  for  analysis 


Summarizing  the  above  in  terms  of  the  ROMC  components, 


we  identify  the  following  the  following  required  DSS 


capabilities: 


REPRESENTATIONS 


-  Lists  of  projects 


-  Lists  of  personnel  scheduled  for  each  project 


-  Lists  of  training  conflicts 
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OPERATIONS 


-  wuery  tne  data  base 

-  Extract  data  subsets  from  multiple  databases 

-  Search  for  matching  parameters 

-  Display  lists 

-  Print  lists 
MEMORY  AIDS 

-  Extracted  data  on  projects 

-  Extracted  data  on  personnel 

-  Work  space  for  saving  information  displayed 

-  Databases 
CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  and  error  messages 

-  Functions  to  "Highlite"  or  mark  selected  data 


DECISION:  What  equipment  and  vehicles  should  we  deploy? 

What  vehicles  should  we  borrow  or  rent?  (PE,  DO, 
OOP) 

INTELLIGENCE 

-  Review  vehicles  and  equipment  required  to  support 
the  project  and  the  time  period  in  which  they  will 
be  required 

-  Review  availability  of  RED  HORSE  equipment  and 
vehicles 

-  Review  availability  of  equipment  at  deployed 
location 

DESIGN 

-  List  tne  RED  HORSE  equipment  projected  to  be 
available  for  the  time  periods  specified 

-  List  the  type  of  equipment  normally  availaole  from 
the  BCE  or  by  local  rental  at  the  project  location 

-  Compute  the  estimated  cost  of  deploying  and 
operating  RED  HORSE  equipment  listed  above 

-  Compute  estimated  rental  cost  for  this  same  type 
equipment 

-  Capture  this  information  and  save  for  use  in  project 
evaluation 

CHOICE 

-  Select  RED  HORSE  equipment  for  project  deployment 

-  Choose  different  time  periods  for  analysis  to 
investigate  feasibility  of  changes  in  tne 
construction  schedule 

Summarizing  the  above  in  terms  of  the  ROMC  components, 
we  identify  the  following  the  following  required  DSS 
capabilities: 

REPRESENTATIONS 

-  Lists  of  projects,  equipment  requirements,  cost  data 

-  Lists  of  equipment  available  by  type  and  time  period 


-  On  screen  data  entry  forms 
OPERATIONS 

-  Query  multiple  dataoases 

-  Extract  and  combine  data  from  multiple  databases 

-  Cross  check  selected  equipment  for  availability 

-  Compute  cost  of  deploying  equipment  and  cost  of 
renting  equipment  oased  on  distance  and  operating 
hours 

MEMORY  AIDS 

-  Extracted  data  on  equipment  available 

-  Extracted  cost  data 

-  Work  space  for  saving  information  displayed 

-  Databases  for  maintaining  equipment  and  cost  data 
CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  and  error  messages 

-  Functions  to  "Highlite"  or  mark  selected  data 


DECISION:  When  should  this  project  be  scheduled?  (DO 0,  DO, 
DE,  CD) 

INTELLIGENCE 

-  Review  current  project  schedule 

-  Examine  project  to  be  scheduled  for  priority  and 
desired  start  and  completion  dates 

-  Determine  manpower  required  by  shop  for  each  day 
from  CPM 

-  Determine  equipment  required  by  type  for  eacn  day 
from  CPM 

-  Review  personnel  and  equipment  availability 

DESIGN 

-  Ada  the  project's  manpower  requirements  to  tne 
current  schedule  and  list  projected  shortages  by 
shop  and  time  period 

-  Add  the  project's  equipment  requirements  to  the 
current  schedule  and  list  projected  shortages  by 
equipment  type  and  time  period 

-  Repeat  this  process  using  different  manpower  and 
equipment  requirements  and  different  time  periods 

-  Update  master  schedule  from  this  analysis 

CHOICE 


-  Select  time  period  for  project  start 

-  Select  project  to  be  scheduled 

-  Select  parameters  to  be  modified  (number  of 
personnel  required,  dates  required,  etc.) 

-  Choose  feasible  solution  to  be  used  to  update  master 
schedule 


Summarizing  tne  above  in  terms  of  the  ROMC  components, 
we  identify  the  following  tne  following  required  DSS 
capabi 1 ities : 

REPRESENTATIONS 

-  Lists  of  projects,  dates,  personnel,  and  equipment 
requirements 

-  Lists  of  manpower  and  equipment  available 

-  Lists  of  projects  scheduled,  priority,  estimated 
start  and  completion  dates 

OPERATIONS 

-  Extract  project  requirements  from  project  planning 
database 

-  Extract  personnel  and  equipment  availacility  data 

-  Combine  data  fields  and  display  results 

-  Update  source  dataoases  with  new  project  schedule, 
personnel,  and  equipment  availability 


MEMORY  AIDS 

-  Extracted  data  on  projects,  personnel,  and  equipment 

-  Work  space  for  saving  information  displayed 

-  Databases  for  maintaining  source  data 
CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  and  error  messages 

-  Functions  to  "Highlite"  or  mark  selected  data 


DECISION:  When  snould  tnis  training  requirement  oe 

conducted?  How  many  quotas  do  I  need  for  tnis 
class?  Who  should  I  schedule  for  this  training? 
( OT ) 

INTELLIGENCE 

-  Review  training  database 

-  Review  personnel  availability 
DESIGN 

-  For  each  training  requirement,  list  number  of 
individuals  due  training  each  month 

-  Sort  above  list  by  date  training  required 

-  For  each  training  type  and  class  date,  list 
individuals  requiring  training 

-  Searcn  for  personnel  availaole  for  each  training 
session 

CHOICE 

-  Select  dates  for  training  to  be  conducted 

-  Select  individuals  for  each  training  session 

Summarizing  the  above  in  terms  of  the  R0;*1C  components 
we  identify  the  following  the  following  required  DSS 
capabilities : 

REPRESENTATIONS 

-  Lists  of  training  requirements 

-  Lists  of  personnel  available  for  training 

-  On  screen  data  entry  forms 
OPERATIONS 

-  Search  master  training  database  and  extract 
individuals  requiring  training 

-  Sort  extracted  database  by  type  training  required 
and  time  period 


-  Seared  personnel  personnel  availability  dataoase  and 
display  individuals  availaole  for  each  class  date 

-  Display  master  training  schedules 

-  Update  databases 

MEMORY  AIDS 

-  Extracted  data  on  training  requirements,  personnel 
availability,  and  training  schedules 

-  Work  space  for  saving  information  displayed 

-  Databases  for  maintaining  source  data 

CONTROL  MECHANISMS 

-  Menus  and  function  Keys 

-  Help  Screens  and  error  messages 

-  Functions  to  "Hignlite"  or  mark  selected  data 

-  Flashing  data  fields  to  indicate  incomplete  data  or 
data  that  requires  updating 
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